This is a note to let you know that I've just added the patch titled
drm/vc4: Release fence after signalling
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-vc4-release-fence-after-signalling.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Stefan Schake <stschake(a)gmail.com>
Date: Sat, 2 Dec 2017 18:40:39 +0100
Subject: drm/vc4: Release fence after signalling
From: Stefan Schake <stschake(a)gmail.com>
[ Upstream commit babc8110057cb9ca542c3c1666cbda4e8ccf9250 ]
We were never releasing the initial fence reference that is obtained
through dma_fence_init.
Link: https://github.com/anholt/linux/issues/122
Fixes: cdec4d361323 ("drm/vc4: Expose dma-buf fences for V3D rendering.")
Signed-off-by: Stefan Schake <stschake(a)gmail.com>
Signed-off-by: Eric Anholt <eric(a)anholt.net>
Reviewed-by: Eric Anholt <eric(a)anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1512236444-301-1-git-send-ema…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/vc4/vc4_gem.c | 4 +++-
drivers/gpu/drm/vc4/vc4_irq.c | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -829,8 +829,10 @@ vc4_complete_exec(struct drm_device *dev
/* If we got force-completed because of GPU reset rather than
* through our IRQ handler, signal the fence now.
*/
- if (exec->fence)
+ if (exec->fence) {
dma_fence_signal(exec->fence);
+ dma_fence_put(exec->fence);
+ }
if (exec->bo) {
for (i = 0; i < exec->bo_count; i++)
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -139,6 +139,7 @@ vc4_irq_finish_render_job(struct drm_dev
list_move_tail(&exec->head, &vc4->job_done_list);
if (exec->fence) {
dma_fence_signal_locked(exec->fence);
+ dma_fence_put(exec->fence);
exec->fence = NULL;
}
vc4_submit_next_render_job(dev);
Patches currently in stable-queue which might be from stschake(a)gmail.com are
queue-4.14/drm-vc4-release-fence-after-signalling.patch
This is a note to let you know that I've just added the patch titled
drm/armada: fix leak of crtc structure
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-armada-fix-leak-of-crtc-structure.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Russell King <rmk+kernel(a)armlinux.org.uk>
Date: Fri, 8 Dec 2017 12:16:22 +0000
Subject: drm/armada: fix leak of crtc structure
From: Russell King <rmk+kernel(a)armlinux.org.uk>
[ Upstream commit 33cd3c07a976e11c3c4cc6b0b3db6760ad1590c5 ]
Fix the leak of the CRTC structure in the failure paths of
armada_drm_crtc_create().
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/armada/armada_crtc.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1225,17 +1225,13 @@ static int armada_drm_crtc_create(struct
ret = devm_request_irq(dev, irq, armada_drm_irq, 0, "armada_drm_crtc",
dcrtc);
- if (ret < 0) {
- kfree(dcrtc);
- return ret;
- }
+ if (ret < 0)
+ goto err_crtc;
if (dcrtc->variant->init) {
ret = dcrtc->variant->init(dcrtc, dev);
- if (ret) {
- kfree(dcrtc);
- return ret;
- }
+ if (ret)
+ goto err_crtc;
}
/* Ensure AXI pipeline is enabled */
@@ -1246,13 +1242,15 @@ static int armada_drm_crtc_create(struct
dcrtc->crtc.port = port;
primary = kzalloc(sizeof(*primary), GFP_KERNEL);
- if (!primary)
- return -ENOMEM;
+ if (!primary) {
+ ret = -ENOMEM;
+ goto err_crtc;
+ }
ret = armada_drm_plane_init(primary);
if (ret) {
kfree(primary);
- return ret;
+ goto err_crtc;
}
ret = drm_universal_plane_init(drm, &primary->base, 0,
@@ -1263,7 +1261,7 @@ static int armada_drm_crtc_create(struct
DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret) {
kfree(primary);
- return ret;
+ goto err_crtc;
}
ret = drm_crtc_init_with_planes(drm, &dcrtc->crtc, &primary->base, NULL,
@@ -1282,6 +1280,9 @@ static int armada_drm_crtc_create(struct
err_crtc_init:
primary->base.funcs->destroy(&primary->base);
+err_crtc:
+ kfree(dcrtc);
+
return ret;
}
Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are
queue-4.14/sfp-fix-rx_los-signal-handling.patch
queue-4.14/drm-armada-fix-leak-of-crtc-structure.patch
queue-4.14/arm-8743-1-bl_switcher-add-module_license-tag.patch
queue-4.14/phylink-ensure-we-take-the-link-down-when-phylink_stop-is-called.patch
This is a note to let you know that I've just added the patch titled
dmaengine: jz4740: disable/unprepare clk if probe fails
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-jz4740-disable-unprepare-clk-if-probe-fails.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
Date: Wed, 6 Dec 2017 14:28:27 +0100
Subject: dmaengine: jz4740: disable/unprepare clk if probe fails
From: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
[ Upstream commit eb9436966fdc84cebdf222952a99898ab46d9bb0 ]
in error path of jz4740_dma_probe(), call clk_disable_unprepare() to clean
up.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 25ce6c35fea0 MIPS: jz4740: Remove custom DMA API
Signed-off-by: Tobias Jordan <Tobias.Jordan(a)elektrobit.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/dma-jz4740.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/dma/dma-jz4740.c
+++ b/drivers/dma/dma-jz4740.c
@@ -555,7 +555,7 @@ static int jz4740_dma_probe(struct platf
ret = dma_async_device_register(dd);
if (ret)
- return ret;
+ goto err_clk;
irq = platform_get_irq(pdev, 0);
ret = request_irq(irq, jz4740_dma_irq, 0, dev_name(&pdev->dev), dmadev);
@@ -568,6 +568,8 @@ static int jz4740_dma_probe(struct platf
err_unregister:
dma_async_device_unregister(dd);
+err_clk:
+ clk_disable_unprepare(dmadev->clk);
return ret;
}
Patches currently in stable-queue which might be from Tobias.Jordan(a)elektrobit.com are
queue-4.14/dmaengine-jz4740-disable-unprepare-clk-if-probe-fails.patch
This is a note to let you know that I've just added the patch titled
dmaengine: ioat: Fix error handling path
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-ioat-fix-error-handling-path.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Date: Fri, 17 Nov 2017 22:37:53 +0100
Subject: dmaengine: ioat: Fix error handling path
From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
[ Upstream commit 5c9afbda911ce20b3f2181d1e440a0222e1027dd ]
If the last test in 'ioat_dma_self_test()' fails, we must release all
the allocated resources and not just part of them.
Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
Acked-by: Dave Jiang <dave.jiang(a)intel.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/ioat/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/dma/ioat/init.c
+++ b/drivers/dma/ioat/init.c
@@ -390,7 +390,7 @@ static int ioat_dma_self_test(struct ioa
if (memcmp(src, dest, IOAT_TEST_SIZE)) {
dev_err(dev, "Self-test copy failed compare, disabling\n");
err = -ENODEV;
- goto free_resources;
+ goto unmap_dma;
}
unmap_dma:
Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are
queue-4.14/dmaengine-ioat-fix-error-handling-path.patch
This is a note to let you know that I've just added the patch titled
dmaengine: at_hdmac: fix potential NULL pointer dereference in atc_prep_dma_interleaved
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-at_hdmac-fix-potential-null-pointer-dereference-in-atc_prep_dma_interleaved.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
Date: Mon, 20 Nov 2017 08:28:14 -0600
Subject: dmaengine: at_hdmac: fix potential NULL pointer dereference in atc_prep_dma_interleaved
From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com>
[ Upstream commit 62a277d43d47e74972de44d33bd3763e31992414 ]
_xt_ is being dereferenced before it is null checked, hence there is a
potential null pointer dereference.
Fix this by moving the pointer dereference after _xt_ has been null
checked.
This issue was detected with the help of Coccinelle.
Fixes: 4483320e241c ("dmaengine: Use Pointer xt after NULL check.")
Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com>
Acked-by: Ludovic Desroches <ludovic.desroches(a)microchip.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/at_hdmac.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -708,7 +708,7 @@ atc_prep_dma_interleaved(struct dma_chan
unsigned long flags)
{
struct at_dma_chan *atchan = to_at_dma_chan(chan);
- struct data_chunk *first = xt->sgl;
+ struct data_chunk *first;
struct at_desc *desc = NULL;
size_t xfer_count;
unsigned int dwidth;
@@ -720,6 +720,8 @@ atc_prep_dma_interleaved(struct dma_chan
if (unlikely(!xt || xt->numf != 1 || !xt->frame_size))
return NULL;
+ first = xt->sgl;
+
dev_info(chan2dev(chan),
"%s: src=%pad, dest=%pad, numf=%d, frame_size=%d, flags=0x%lx\n",
__func__, &xt->src_start, &xt->dst_start, xt->numf,
Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are
queue-4.14/dmaengine-at_hdmac-fix-potential-null-pointer-dereference-in-atc_prep_dma_interleaved.patch
This is a note to let you know that I've just added the patch titled
clk: fix a panic error caused by accessing NULL pointer
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-fix-a-panic-error-caused-by-accessing-null-pointer.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Cai Li <cai.li(a)spreadtrum.com>
Date: Tue, 21 Nov 2017 17:24:38 +0800
Subject: clk: fix a panic error caused by accessing NULL pointer
From: Cai Li <cai.li(a)spreadtrum.com>
[ Upstream commit 975b820b6836b6b6c42fb84cd2e772e2b41bca67 ]
In some cases the clock parent would be set NULL when doing re-parent,
it will cause a NULL pointer accessing if clk_set trace event is
enabled.
This patch sets the parent as "none" if the input parameter is NULL.
Fixes: dfc202ead312 (clk: Add tracepoints for hardware operations)
Signed-off-by: Cai Li <cai.li(a)spreadtrum.com>
Signed-off-by: Chunyan Zhang <chunyan.zhang(a)spreadtrum.com>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/trace/events/clk.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/trace/events/clk.h
+++ b/include/trace/events/clk.h
@@ -134,12 +134,12 @@ DECLARE_EVENT_CLASS(clk_parent,
TP_STRUCT__entry(
__string( name, core->name )
- __string( pname, parent->name )
+ __string( pname, parent ? parent->name : "none" )
),
TP_fast_assign(
__assign_str(name, core->name);
- __assign_str(pname, parent->name);
+ __assign_str(pname, parent ? parent->name : "none");
),
TP_printk("%s %s", __get_str(name), __get_str(pname))
Patches currently in stable-queue which might be from cai.li(a)spreadtrum.com are
queue-4.14/clk-fix-a-panic-error-caused-by-accessing-null-pointer.patch
This is a note to let you know that I've just added the patch titled
btrfs: Fix quota reservation leak on preallocated files
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
btrfs-fix-quota-reservation-leak-on-preallocated-files.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Justin Maggard <jmaggard10(a)gmail.com>
Date: Mon, 30 Oct 2017 15:29:10 -0700
Subject: btrfs: Fix quota reservation leak on preallocated files
From: Justin Maggard <jmaggard10(a)gmail.com>
[ Upstream commit b430b7751286b3acff2d324553c8cec4f1e87764 ]
Commit c6887cd11149 ("Btrfs: don't do nocow check unless we have to")
changed the behavior of __btrfs_buffered_write() so that it first tries
to get a data space reservation, and then skips the relatively expensive
nocow check if the reservation succeeded.
If we have quotas enabled, the data space reservation also includes a
quota reservation. But in the rewrite case, the space has already been
accounted for in qgroups. So btrfs_check_data_free_space() increases
the quota reservation, but it never gets decreased when the data
actually gets written and overwrites the pre-existing data. So we're
left with both the qgroup and qgroup reservation accounting for the same
space.
This commit adds the missing btrfs_qgroup_free_data() call in the case
of BTRFS_ORDERED_PREALLOC extents.
Fixes: c6887cd11149 ("Btrfs: don't do nocow check unless we have to")
Signed-off-by: Justin Maggard <jmaggard(a)netgear.com>
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/inode.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -3016,6 +3016,8 @@ static int btrfs_finish_ordered_io(struc
compress_type = ordered_extent->compress_type;
if (test_bit(BTRFS_ORDERED_PREALLOC, &ordered_extent->flags)) {
BUG_ON(compress_type);
+ btrfs_qgroup_free_data(inode, NULL, ordered_extent->file_offset,
+ ordered_extent->len);
ret = btrfs_mark_extent_written(trans, BTRFS_I(inode),
ordered_extent->file_offset,
ordered_extent->file_offset +
Patches currently in stable-queue which might be from jmaggard10(a)gmail.com are
queue-4.14/btrfs-fix-quota-reservation-leak-on-preallocated-files.patch
This is a note to let you know that I've just added the patch titled
btrfs: Fix possible off-by-one in btrfs_search_path_in_tree
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
btrfs-fix-possible-off-by-one-in-btrfs_search_path_in_tree.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Fri, 1 Dec 2017 11:19:42 +0200
Subject: btrfs: Fix possible off-by-one in btrfs_search_path_in_tree
From: Nikolay Borisov <nborisov(a)suse.com>
[ Upstream commit c8bcbfbd239ed60a6562964b58034ac8a25f4c31 ]
The name char array passed to btrfs_search_path_in_tree is of size
BTRFS_INO_LOOKUP_PATH_MAX (4080). So the actual accessible char indexes
are in the range of [0, 4079]. Currently the code uses the define but this
represents an off-by-one.
Implications:
Size of btrfs_ioctl_ino_lookup_args is 4096, so the new byte will be
written to extra space, not some padding that could be provided by the
allocator.
btrfs-progs store the arguments on stack, but kernel does own copy of
the ioctl buffer and the off-by-one overwrite does not affect userspace,
but the ending 0 might be lost.
Kernel ioctl buffer is allocated dynamically so we're overwriting
somebody else's memory, and the ioctl is privileged if args.objectid is
not 256. Which is in most cases, but resolving a subvolume stored in
another directory will trigger that path.
Before this patch the buffer was one byte larger, but then the -1 was
not added.
Fixes: ac8e9819d71f907 ("Btrfs: add search and inode lookup ioctls")
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
[ added implications ]
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2221,7 +2221,7 @@ static noinline int btrfs_search_path_in
if (!path)
return -ENOMEM;
- ptr = &name[BTRFS_INO_LOOKUP_PATH_MAX];
+ ptr = &name[BTRFS_INO_LOOKUP_PATH_MAX - 1];
key.objectid = tree_id;
key.type = BTRFS_ROOT_ITEM_KEY;
Patches currently in stable-queue which might be from nborisov(a)suse.com are
queue-4.14/btrfs-fix-possible-off-by-one-in-btrfs_search_path_in_tree.patch
This is a note to let you know that I've just added the patch titled
Btrfs: disable FUA if mounted with nobarrier
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
btrfs-disable-fua-if-mounted-with-nobarrier.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Omar Sandoval <osandov(a)fb.com>
Date: Tue, 5 Dec 2017 22:54:02 -0800
Subject: Btrfs: disable FUA if mounted with nobarrier
From: Omar Sandoval <osandov(a)fb.com>
[ Upstream commit 1b9e619c5bc8235cfba3dc4ced2fb0e3554a05d4 ]
I was seeing disk flushes still happening when I mounted a Btrfs
filesystem with nobarrier for testing. This is because we use FUA to
write out the first super block, and on devices without FUA support, the
block layer translates FUA to a flush. Even on devices supporting true
FUA, using FUA when we asked for no barriers is surprising.
Fixes: 387125fc722a8ed ("Btrfs: fix barrier flushes")
Signed-off-by: Omar Sandoval <osandov(a)fb.com>
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/disk-io.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3391,6 +3391,7 @@ static int write_dev_supers(struct btrfs
int errors = 0;
u32 crc;
u64 bytenr;
+ int op_flags;
if (max_mirrors == 0)
max_mirrors = BTRFS_SUPER_MIRROR_MAX;
@@ -3433,13 +3434,10 @@ static int write_dev_supers(struct btrfs
* we fua the first super. The others we allow
* to go down lazy.
*/
- if (i == 0) {
- ret = btrfsic_submit_bh(REQ_OP_WRITE,
- REQ_SYNC | REQ_FUA | REQ_META | REQ_PRIO, bh);
- } else {
- ret = btrfsic_submit_bh(REQ_OP_WRITE,
- REQ_SYNC | REQ_META | REQ_PRIO, bh);
- }
+ op_flags = REQ_SYNC | REQ_META | REQ_PRIO;
+ if (i == 0 && !btrfs_test_opt(device->fs_info, NOBARRIER))
+ op_flags |= REQ_FUA;
+ ret = btrfsic_submit_bh(REQ_OP_WRITE, op_flags, bh);
if (ret)
errors++;
}
Patches currently in stable-queue which might be from osandov(a)fb.com are
queue-4.14/btrfs-disable-fua-if-mounted-with-nobarrier.patch