This is a note to let you know that I've just added the patch titled
mvpp2: fix multicast address filter
to the 4.15-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:
mvpp2-fix-multicast-address-filter.patch
and it can be found in the queue-4.15 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 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Sun, 11 Feb 2018 18:10:28 -0500
Subject: mvpp2: fix multicast address filter
From: Mikulas Patocka <mpatocka(a)redhat.com>
commit 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3 upstream.
IPv6 doesn't work on the MacchiatoBIN board. It is caused by broken
multicast address filter in the mvpp2 driver.
The driver loads doesn't load any multicast entries if "allmulti" is not
set. This condition should be reversed.
The condition !netdev_mc_empty(dev) is useless (because
netdev_for_each_mc_addr is nop if the list is empty).
This patch also fixes a possible overflow of the multicast list - if
mvpp2_prs_mac_da_accept fails, we set the allmulti flag and retry.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/marvell/mvpp2.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -7127,6 +7127,7 @@ static void mvpp2_set_rx_mode(struct net
int id = port->id;
bool allmulti = dev->flags & IFF_ALLMULTI;
+retry:
mvpp2_prs_mac_promisc_set(priv, id, dev->flags & IFF_PROMISC);
mvpp2_prs_mac_multi_set(priv, id, MVPP2_PE_MAC_MC_ALL, allmulti);
mvpp2_prs_mac_multi_set(priv, id, MVPP2_PE_MAC_MC_IP6, allmulti);
@@ -7134,9 +7135,13 @@ static void mvpp2_set_rx_mode(struct net
/* Remove all port->id's mcast enries */
mvpp2_prs_mcast_del_all(priv, id);
- if (allmulti && !netdev_mc_empty(dev)) {
- netdev_for_each_mc_addr(ha, dev)
- mvpp2_prs_mac_da_accept(priv, id, ha->addr, true);
+ if (!allmulti) {
+ netdev_for_each_mc_addr(ha, dev) {
+ if (mvpp2_prs_mac_da_accept(priv, id, ha->addr, true)) {
+ allmulti = true;
+ goto retry;
+ }
+ }
}
}
Patches currently in stable-queue which might be from mpatocka(a)redhat.com are
queue-4.15/mvpp2-fix-multicast-address-filter.patch
queue-4.15/blk-wbt-account-flush-requests-correctly.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: vf610: set correct ooblayout
to the 4.15-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:
mtd-nand-vf610-set-correct-ooblayout.patch
and it can be found in the queue-4.15 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 ea56fb282368ea08c2a313af6b55cb597aec4db1 Mon Sep 17 00:00:00 2001
From: Stefan Agner <stefan(a)agner.ch>
Date: Fri, 9 Feb 2018 13:21:42 +0100
Subject: mtd: nand: vf610: set correct ooblayout
From: Stefan Agner <stefan(a)agner.ch>
commit ea56fb282368ea08c2a313af6b55cb597aec4db1 upstream.
With commit 3cf32d180227 ("mtd: nand: vf610: switch to
mtd_ooblayout_ops") the driver started to use the NAND cores
default large page ooblayout. However, shortly after commit
6a623e076944 ("mtd: nand: add ooblayout for old hamming layout")
changed the default layout to the old hamming layout, which is
not what vf610_nfc is using. Specify the default large page
layout explicitly.
Fixes: 6a623e076944 ("mtd: nand: add ooblayout for old hamming layout")
Cc: <stable(a)vger.kernel.org> # v4.12+
Signed-off-by: Stefan Agner <stefan(a)agner.ch>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/vf610_nfc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -752,10 +752,8 @@ static int vf610_nfc_probe(struct platfo
if (mtd->oobsize > 64)
mtd->oobsize = 64;
- /*
- * mtd->ecclayout is not specified here because we're using the
- * default large page ECC layout defined in NAND core.
- */
+ /* Use default large page ECC layout defined in NAND core */
+ mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
if (chip->ecc.strength == 32) {
nfc->ecc_mode = ECC_60_BYTE;
chip->ecc.bytes = 60;
Patches currently in stable-queue which might be from stefan(a)agner.ch are
queue-4.15/mtd-nand-vf610-set-correct-ooblayout.patch
This is a note to let you know that I've just added the patch titled
iscsi-target: make sure to wake up sleeping login worker
to the 4.15-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:
iscsi-target-make-sure-to-wake-up-sleeping-login-worker.patch
and it can be found in the queue-4.15 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 1c130ae00b769a2e2df41bad3d6051ee8234b636 Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Fri, 19 Jan 2018 14:36:29 +0100
Subject: iscsi-target: make sure to wake up sleeping login worker
From: Florian Westphal <fw(a)strlen.de>
commit 1c130ae00b769a2e2df41bad3d6051ee8234b636 upstream.
Mike Christie reports:
Starting in 4.14 iscsi logins will fail around 50% of the time.
Problem appears to be that iscsi_target_sk_data_ready() callback may
return without doing anything in case it finds the login work queue
is still blocked in sock_recvmsg().
Nicholas Bellinger says:
It would indicate users providing their own ->sk_data_ready() callback
must be responsible for waking up a kthread context blocked on
sock_recvmsg(..., MSG_WAITALL), when a second ->sk_data_ready() is
received before the first sock_recvmsg(..., MSG_WAITALL) completes.
So, do this and invoke the original data_ready() callback -- in
case of tcp sockets this takes care of waking the thread.
Disclaimer: I do not understand why this problem did not show up before
tcp prequeue removal.
(Drop WARN_ON usage - nab)
Reported-by: Mike Christie <mchristi(a)redhat.com>
Bisected-by: Mike Christie <mchristi(a)redhat.com>
Tested-by: Mike Christie <mchristi(a)redhat.com>
Diagnosed-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Fixes: e7942d0633c4 ("tcp: remove prequeue support")
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Cc: stable(a)vger.kernel.org # 4.14+
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/iscsi/iscsi_target_nego.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/target/iscsi/iscsi_target_nego.c
+++ b/drivers/target/iscsi/iscsi_target_nego.c
@@ -432,6 +432,9 @@ static void iscsi_target_sk_data_ready(s
if (test_and_set_bit(LOGIN_FLAGS_READ_ACTIVE, &conn->login_flags)) {
write_unlock_bh(&sk->sk_callback_lock);
pr_debug("Got LOGIN_FLAGS_READ_ACTIVE=1, conn: %p >>>>\n", conn);
+ if (iscsi_target_sk_data_ready == conn->orig_data_ready)
+ return;
+ conn->orig_data_ready(sk);
return;
}
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.15/iscsi-target-make-sure-to-wake-up-sleeping-login-worker.patch
This is a note to let you know that I've just added the patch titled
dm: correctly handle chained bios in dec_pending()
to the 4.15-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:
dm-correctly-handle-chained-bios-in-dec_pending.patch
and it can be found in the queue-4.15 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 8dd601fa8317243be887458c49f6c29c2f3d719f Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb(a)suse.com>
Date: Thu, 15 Feb 2018 20:00:15 +1100
Subject: dm: correctly handle chained bios in dec_pending()
From: NeilBrown <neilb(a)suse.com>
commit 8dd601fa8317243be887458c49f6c29c2f3d719f upstream.
dec_pending() is given an error status (possibly 0) to be recorded
against a bio. It can be called several times on the one 'struct
dm_io', and it is careful to only assign a non-zero error to
io->status. However when it then assigned io->status to bio->bi_status,
it is not careful and could overwrite a genuine error status with 0.
This can happen when chained bios are in use. If a bio is chained
beneath the bio that this dm_io is handling, the child bio might
complete and set bio->bi_status before the dm_io completes.
This has been possible since chained bios were introduced in 3.14, and
has become a lot easier to trigger with commit 18a25da84354 ("dm: ensure
bio submission follows a depth-first tree walk") as that commit caused
dm to start using chained bios itself.
A particular failure mode is that if a bio spans an 'error' target and a
working target, the 'error' fragment will complete instantly and set the
->bi_status, and the other fragment will normally complete a little
later, and will clear ->bi_status.
The fix is simply to only assign io_error to bio->bi_status when
io_error is not zero.
Reported-and-tested-by: Milan Broz <gmazyland(a)gmail.com>
Cc: stable(a)vger.kernel.org (v3.14+)
Signed-off-by: NeilBrown <neilb(a)suse.com>
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/dm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -817,7 +817,8 @@ static void dec_pending(struct dm_io *io
queue_io(md, bio);
} else {
/* done with normal IO or empty flush */
- bio->bi_status = io_error;
+ if (io_error)
+ bio->bi_status = io_error;
bio_endio(bio);
}
}
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-4.15/dm-correctly-handle-chained-bios-in-dec_pending.patch
This is a note to let you know that I've just added the patch titled
Btrfs: fix use-after-free on root->orphan_block_rsv
to the 4.15-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-use-after-free-on-root-orphan_block_rsv.patch
and it can be found in the queue-4.15 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 1a932ef4e47984dee227834667b5ff5a334e4805 Mon Sep 17 00:00:00 2001
From: Liu Bo <bo.li.liu(a)oracle.com>
Date: Thu, 25 Jan 2018 11:02:54 -0700
Subject: Btrfs: fix use-after-free on root->orphan_block_rsv
From: Liu Bo <bo.li.liu(a)oracle.com>
commit 1a932ef4e47984dee227834667b5ff5a334e4805 upstream.
I got these from running generic/475,
WARNING: CPU: 0 PID: 26384 at fs/btrfs/inode.c:3326 btrfs_orphan_commit_root+0x1ac/0x2b0 [btrfs]
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
IP: btrfs_block_rsv_release+0x1c/0x70 [btrfs]
Call Trace:
btrfs_orphan_release_metadata+0x9f/0x200 [btrfs]
btrfs_orphan_del+0x10d/0x170 [btrfs]
btrfs_setattr+0x500/0x640 [btrfs]
notify_change+0x7ae/0x870
do_truncate+0xca/0x130
vfs_truncate+0x2ee/0x3d0
do_sys_truncate+0xaf/0xf0
SyS_truncate+0xe/0x10
entry_SYSCALL_64_fastpath+0x1f/0x96
The race is between btrfs_orphan_commit_root and btrfs_orphan_del,
t1 t2
btrfs_orphan_commit_root btrfs_orphan_del
spin_lock
check (&root->orphan_inodes)
root->orphan_block_rsv = NULL;
spin_unlock
atomic_dec(&root->orphan_inodes);
access root->orphan_block_rsv
Accessing root->orphan_block_rsv must be done before decreasing
root->orphan_inodes.
cc: <stable(a)vger.kernel.org> v3.12+
Fixes: 703c88e03524 ("Btrfs: fix tracking of orphan inode count")
Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com>
Reviewed-by: Josef Bacik <jbacik(a)fb.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/inode.c | 34 +++++++++++++++++++++-------------
1 file changed, 21 insertions(+), 13 deletions(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -3369,6 +3369,11 @@ int btrfs_orphan_add(struct btrfs_trans_
ret = btrfs_orphan_reserve_metadata(trans, inode);
ASSERT(!ret);
if (ret) {
+ /*
+ * dec doesn't need spin_lock as ->orphan_block_rsv
+ * would be released only if ->orphan_inodes is
+ * zero.
+ */
atomic_dec(&root->orphan_inodes);
clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED,
&inode->runtime_flags);
@@ -3383,12 +3388,17 @@ int btrfs_orphan_add(struct btrfs_trans_
if (insert >= 1) {
ret = btrfs_insert_orphan_item(trans, root, btrfs_ino(inode));
if (ret) {
- atomic_dec(&root->orphan_inodes);
if (reserve) {
clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED,
&inode->runtime_flags);
btrfs_orphan_release_metadata(inode);
}
+ /*
+ * btrfs_orphan_commit_root may race with us and set
+ * ->orphan_block_rsv to zero, in order to avoid that,
+ * decrease ->orphan_inodes after everything is done.
+ */
+ atomic_dec(&root->orphan_inodes);
if (ret != -EEXIST) {
clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM,
&inode->runtime_flags);
@@ -3420,28 +3430,26 @@ static int btrfs_orphan_del(struct btrfs
{
struct btrfs_root *root = inode->root;
int delete_item = 0;
- int release_rsv = 0;
int ret = 0;
- spin_lock(&root->orphan_lock);
if (test_and_clear_bit(BTRFS_INODE_HAS_ORPHAN_ITEM,
&inode->runtime_flags))
delete_item = 1;
+ if (delete_item && trans)
+ ret = btrfs_del_orphan_item(trans, root, btrfs_ino(inode));
+
if (test_and_clear_bit(BTRFS_INODE_ORPHAN_META_RESERVED,
&inode->runtime_flags))
- release_rsv = 1;
- spin_unlock(&root->orphan_lock);
+ btrfs_orphan_release_metadata(inode);
- if (delete_item) {
+ /*
+ * btrfs_orphan_commit_root may race with us and set ->orphan_block_rsv
+ * to zero, in order to avoid that, decrease ->orphan_inodes after
+ * everything is done.
+ */
+ if (delete_item)
atomic_dec(&root->orphan_inodes);
- if (trans)
- ret = btrfs_del_orphan_item(trans, root,
- btrfs_ino(inode));
- }
-
- if (release_rsv)
- btrfs_orphan_release_metadata(inode);
return ret;
}
Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are
queue-4.15/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch
queue-4.15/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch
queue-4.15/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch
queue-4.15/btrfs-fix-extent-state-leak-from-tree-log.patch
queue-4.15/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch
queue-4.15/btrfs-fix-deadlock-in-run_delalloc_nocow.patch
This is a note to let you know that I've just added the patch titled
Btrfs: fix unexpected -EEXIST when creating new inode
to the 4.15-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-unexpected-eexist-when-creating-new-inode.patch
and it can be found in the queue-4.15 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 900c9981680067573671ecc5cbfa7c5770be3a40 Mon Sep 17 00:00:00 2001
From: Liu Bo <bo.li.liu(a)oracle.com>
Date: Thu, 25 Jan 2018 11:02:56 -0700
Subject: Btrfs: fix unexpected -EEXIST when creating new inode
From: Liu Bo <bo.li.liu(a)oracle.com>
commit 900c9981680067573671ecc5cbfa7c5770be3a40 upstream.
The highest objectid, which is assigned to new inode, is decided at
the time of initializing fs roots. However, in cases where log replay
gets processed, the btree which fs root owns might be changed, so we
have to search it again for the highest objectid, otherwise creating
new inode would end up with -EEXIST.
cc: <stable(a)vger.kernel.org> v4.4-rc6+
Fixes: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots")
Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com>
Reviewed-by: Josef Bacik <jbacik(a)fb.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/tree-log.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -28,6 +28,7 @@
#include "hash.h"
#include "compression.h"
#include "qgroup.h"
+#include "inode-map.h"
/* magic values for the inode_only field in btrfs_log_inode:
*
@@ -5715,6 +5716,23 @@ again:
path);
}
+ if (!ret && wc.stage == LOG_WALK_REPLAY_ALL) {
+ struct btrfs_root *root = wc.replay_dest;
+
+ btrfs_release_path(path);
+
+ /*
+ * We have just replayed everything, and the highest
+ * objectid of fs roots probably has changed in case
+ * some inode_item's got replayed.
+ *
+ * root->objectid_mutex is not acquired as log replay
+ * could only happen during mount.
+ */
+ ret = btrfs_find_highest_objectid(root,
+ &root->highest_objectid);
+ }
+
key.offset = found_key.offset - 1;
wc.replay_dest->log_root = NULL;
free_extent_buffer(log->node);
Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are
queue-4.15/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch
queue-4.15/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch
queue-4.15/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch
queue-4.15/btrfs-fix-extent-state-leak-from-tree-log.patch
queue-4.15/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch
queue-4.15/btrfs-fix-deadlock-in-run_delalloc_nocow.patch
This is a note to let you know that I've just added the patch titled
Btrfs: fix extent state leak from tree log
to the 4.15-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-extent-state-leak-from-tree-log.patch
and it can be found in the queue-4.15 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 55237a5f2431a72435e3ed39e4306e973c0446b7 Mon Sep 17 00:00:00 2001
From: Liu Bo <bo.li.liu(a)oracle.com>
Date: Thu, 25 Jan 2018 11:02:52 -0700
Subject: Btrfs: fix extent state leak from tree log
From: Liu Bo <bo.li.liu(a)oracle.com>
commit 55237a5f2431a72435e3ed39e4306e973c0446b7 upstream.
It's possible that btrfs_sync_log() bails out after one of the two
btrfs_write_marked_extents() which convert extent state's state bit into
EXTENT_NEED_WAIT from EXTENT_DIRTY/EXTENT_NEW, however only EXTENT_DIRTY
and EXTENT_NEW are searched by free_log_tree() so that those extent states
with EXTENT_NEED_WAIT lead to memory leak.
cc: <stable(a)vger.kernel.org>
Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com>
Reviewed-by: Josef Bacik <jbacik(a)fb.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/tree-log.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -3049,13 +3049,14 @@ static void free_log_tree(struct btrfs_t
while (1) {
ret = find_first_extent_bit(&log->dirty_log_pages,
- 0, &start, &end, EXTENT_DIRTY | EXTENT_NEW,
+ 0, &start, &end,
+ EXTENT_DIRTY | EXTENT_NEW | EXTENT_NEED_WAIT,
NULL);
if (ret)
break;
clear_extent_bits(&log->dirty_log_pages, start, end,
- EXTENT_DIRTY | EXTENT_NEW);
+ EXTENT_DIRTY | EXTENT_NEW | EXTENT_NEED_WAIT);
}
/*
Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are
queue-4.15/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch
queue-4.15/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch
queue-4.15/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch
queue-4.15/btrfs-fix-extent-state-leak-from-tree-log.patch
queue-4.15/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch
queue-4.15/btrfs-fix-deadlock-in-run_delalloc_nocow.patch
This is a note to let you know that I've just added the patch titled
Btrfs: fix crash due to not cleaning up tree log block's dirty bits
to the 4.15-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-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch
and it can be found in the queue-4.15 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 1846430c24d66e85cc58286b3319c82cd54debb2 Mon Sep 17 00:00:00 2001
From: Liu Bo <bo.li.liu(a)oracle.com>
Date: Thu, 25 Jan 2018 11:02:51 -0700
Subject: Btrfs: fix crash due to not cleaning up tree log block's dirty bits
From: Liu Bo <bo.li.liu(a)oracle.com>
commit 1846430c24d66e85cc58286b3319c82cd54debb2 upstream.
In cases that the whole fs flips into readonly status due to failures in
critical sections, then log tree's blocks are still dirty, and this leads
to a crash during umount time, the crash is about use-after-free,
umount
-> close_ctree
-> stop workers
-> iput(btree_inode)
-> iput_final
-> write_inode_now
-> ...
-> queue job on stop'd workers
cc: <stable(a)vger.kernel.org> v3.12+
Fixes: 681ae50917df ("Btrfs: cleanup reserved space when freeing tree log on error")
Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com>
Reviewed-by: Josef Bacik <jbacik(a)fb.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/tree-log.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -2494,6 +2494,9 @@ static noinline int walk_down_log_tree(s
clean_tree_block(fs_info, next);
btrfs_wait_tree_block_writeback(next);
btrfs_tree_unlock(next);
+ } else {
+ if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags))
+ clear_extent_buffer_dirty(next);
}
WARN_ON(root_owner !=
@@ -2574,6 +2577,9 @@ static noinline int walk_up_log_tree(str
clean_tree_block(fs_info, next);
btrfs_wait_tree_block_writeback(next);
btrfs_tree_unlock(next);
+ } else {
+ if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags))
+ clear_extent_buffer_dirty(next);
}
WARN_ON(root_owner != BTRFS_TREE_LOG_OBJECTID);
@@ -2652,6 +2658,9 @@ static int walk_log_tree(struct btrfs_tr
clean_tree_block(fs_info, next);
btrfs_wait_tree_block_writeback(next);
btrfs_tree_unlock(next);
+ } else {
+ if (test_and_clear_bit(EXTENT_BUFFER_DIRTY, &next->bflags))
+ clear_extent_buffer_dirty(next);
}
WARN_ON(log->root_key.objectid !=
Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are
queue-4.15/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch
queue-4.15/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch
queue-4.15/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch
queue-4.15/btrfs-fix-extent-state-leak-from-tree-log.patch
queue-4.15/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch
queue-4.15/btrfs-fix-deadlock-in-run_delalloc_nocow.patch
This is a note to let you know that I've just added the patch titled
Btrfs: fix deadlock in run_delalloc_nocow
to the 4.15-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-deadlock-in-run_delalloc_nocow.patch
and it can be found in the queue-4.15 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 e89166990f11c3f21e1649d760dd35f9e410321c Mon Sep 17 00:00:00 2001
From: Liu Bo <bo.li.liu(a)oracle.com>
Date: Thu, 25 Jan 2018 11:02:50 -0700
Subject: Btrfs: fix deadlock in run_delalloc_nocow
From: Liu Bo <bo.li.liu(a)oracle.com>
commit e89166990f11c3f21e1649d760dd35f9e410321c upstream.
@cur_offset is not set back to what it should be (@cow_start) if
btrfs_next_leaf() returns something wrong, and the range [cow_start,
cur_offset) remains locked forever.
cc: <stable(a)vger.kernel.org>
Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com>
Reviewed-by: Josef Bacik <jbacik(a)fb.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/inode.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -1330,8 +1330,11 @@ next_slot:
leaf = path->nodes[0];
if (path->slots[0] >= btrfs_header_nritems(leaf)) {
ret = btrfs_next_leaf(root, path);
- if (ret < 0)
+ if (ret < 0) {
+ if (cow_start != (u64)-1)
+ cur_offset = cow_start;
goto error;
+ }
if (ret > 0)
break;
leaf = path->nodes[0];
Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are
queue-4.15/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch
queue-4.15/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch
queue-4.15/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch
queue-4.15/btrfs-fix-extent-state-leak-from-tree-log.patch
queue-4.15/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch
queue-4.15/btrfs-fix-deadlock-in-run_delalloc_nocow.patch
This is a note to let you know that I've just added the patch titled
Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly
to the 4.15-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-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch
and it can be found in the queue-4.15 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 e8f1bc1493855e32b7a2a019decc3c353d94daf6 Mon Sep 17 00:00:00 2001
From: Liu Bo <bo.li.liu(a)oracle.com>
Date: Thu, 25 Jan 2018 11:02:53 -0700
Subject: Btrfs: fix btrfs_evict_inode to handle abnormal inodes correctly
From: Liu Bo <bo.li.liu(a)oracle.com>
commit e8f1bc1493855e32b7a2a019decc3c353d94daf6 upstream.
This regression is introduced in
commit 3d48d9810de4 ("btrfs: Handle uninitialised inode eviction").
There are two problems,
a) it is ->destroy_inode() that does the final free on inode, not
->evict_inode(),
b) clear_inode() must be called before ->evict_inode() returns.
This could end up hitting BUG_ON(inode->i_state != (I_FREEING | I_CLEAR));
in evict() because I_CLEAR is set in clear_inode().
Fixes: commit 3d48d9810de4 ("btrfs: Handle uninitialised inode eviction")
Cc: <stable(a)vger.kernel.org> # v4.7-rc6+
Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com>
Reviewed-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Josef Bacik <jbacik(a)fb.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -5266,7 +5266,7 @@ void btrfs_evict_inode(struct inode *ino
trace_btrfs_inode_evict(inode);
if (!root) {
- kmem_cache_free(btrfs_inode_cachep, BTRFS_I(inode));
+ clear_inode(inode);
return;
}
Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are
queue-4.15/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch
queue-4.15/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch
queue-4.15/btrfs-fix-use-after-free-on-root-orphan_block_rsv.patch
queue-4.15/btrfs-fix-extent-state-leak-from-tree-log.patch
queue-4.15/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch
queue-4.15/btrfs-fix-deadlock-in-run_delalloc_nocow.patch