March 2023 - Linux-stable-mirror

FAILED: patch "[PATCH] udf: Fix off-by-one error when discarding preallocation" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x f54aa97fb7e5329a373f9df4e5e213ced4fc8759 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '1678110005174144(a)kroah.com' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: f54aa97fb7e5 ("udf: Fix off-by-one error when discarding preallocation") f3a30be77750 ("udf: Factor out block mapping into udf_map_block()") a27b2923de7e ("udf: Move udf_expand_dir_adinicb() to its callsite") 57bda9fb169d ("udf: Convert udf_expand_dir_adinicb() to new directory iteration") 16d055656814 ("udf: Discard preallocation before extending file with a hole") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f54aa97fb7e5329a373f9df4e5e213ced4fc8759 Mon Sep 17 00:00:00 2001 From: Jan Kara <jack(a)suse.cz> Date: Mon, 23 Jan 2023 14:29:15 +0100 Subject: [PATCH] udf: Fix off-by-one error when discarding preallocation The condition determining whether the preallocation can be used had an off-by-one error so we didn't discard preallocation when new allocation was just following it. This can then confuse code in inode_getblk(). CC: stable(a)vger.kernel.org Fixes: 16d055656814 ("udf: Discard preallocation before extending file with a hole") Signed-off-by: Jan Kara <jack(a)suse.cz> diff --git a/fs/udf/inode.c b/fs/udf/inode.c index 51deada8b928..ee440d16411e 100644 --- a/fs/udf/inode.c +++ b/fs/udf/inode.c @@ -361,7 +361,7 @@ static int udf_map_block(struct inode *inode, struct udf_map_rq *map) * Block beyond EOF and prealloc extents? Just discard preallocation * as it is not useful and complicates things. */ - if (((loff_t)map->lblk) << inode->i_blkbits > iinfo->i_lenExtents) + if (((loff_t)map->lblk) << inode->i_blkbits >= iinfo->i_lenExtents) udf_discard_prealloc(inode); udf_clear_extent_cache(inode); err = inode_getblk(inode, map);

1 year, 10 months

1
0
0 0

FAILED: patch "[PATCH] udf: Fix off-by-one error when discarding preallocation" failed to apply to 6.2-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.2-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.2.y git checkout FETCH_HEAD git cherry-pick -x f54aa97fb7e5329a373f9df4e5e213ced4fc8759 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '167811000425499(a)kroah.com' --subject-prefix 'PATCH 6.2.y' HEAD^.. Possible dependencies: f54aa97fb7e5 ("udf: Fix off-by-one error when discarding preallocation") f3a30be77750 ("udf: Factor out block mapping into udf_map_block()") a27b2923de7e ("udf: Move udf_expand_dir_adinicb() to its callsite") 57bda9fb169d ("udf: Convert udf_expand_dir_adinicb() to new directory iteration") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f54aa97fb7e5329a373f9df4e5e213ced4fc8759 Mon Sep 17 00:00:00 2001 From: Jan Kara <jack(a)suse.cz> Date: Mon, 23 Jan 2023 14:29:15 +0100 Subject: [PATCH] udf: Fix off-by-one error when discarding preallocation The condition determining whether the preallocation can be used had an off-by-one error so we didn't discard preallocation when new allocation was just following it. This can then confuse code in inode_getblk(). CC: stable(a)vger.kernel.org Fixes: 16d055656814 ("udf: Discard preallocation before extending file with a hole") Signed-off-by: Jan Kara <jack(a)suse.cz> diff --git a/fs/udf/inode.c b/fs/udf/inode.c index 51deada8b928..ee440d16411e 100644 --- a/fs/udf/inode.c +++ b/fs/udf/inode.c @@ -361,7 +361,7 @@ static int udf_map_block(struct inode *inode, struct udf_map_rq *map) * Block beyond EOF and prealloc extents? Just discard preallocation * as it is not useful and complicates things. */ - if (((loff_t)map->lblk) << inode->i_blkbits > iinfo->i_lenExtents) + if (((loff_t)map->lblk) << inode->i_blkbits >= iinfo->i_lenExtents) udf_discard_prealloc(inode); udf_clear_extent_cache(inode); err = inode_getblk(inode, map);

1 year, 10 months

1
0
0 0

FAILED: patch "[PATCH] udf: Preserve link count of system files" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x fc8033a34a3ca7d23353e645e6dde5d364ac5f12 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '167810996089240(a)kroah.com' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: fc8033a34a3c ("udf: Preserve link count of system files") 382a2287bf9c ("udf: Remove pointless union in udf_inode_info") 044e2e26f214 ("udf: Avoid accessing uninitialized data on failed inode read") ab9a3a737284 ("udf: reduce leakage of blocks related to named streams") d288d95842f1 ("udf: Fix BUG on corrupted inode") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From fc8033a34a3ca7d23353e645e6dde5d364ac5f12 Mon Sep 17 00:00:00 2001 From: Jan Kara <jack(a)suse.cz> Date: Tue, 3 Jan 2023 09:56:56 +0100 Subject: [PATCH] udf: Preserve link count of system files System files in UDF filesystem have link count 0. To not confuse VFS we fudge the link count to be 1 when reading such inodes however we forget to restore the link count of 0 when writing such inodes. Fix that. CC: stable(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> diff --git a/fs/udf/inode.c b/fs/udf/inode.c index 31965c3798f2..9ee269d3d546 100644 --- a/fs/udf/inode.c +++ b/fs/udf/inode.c @@ -1301,6 +1301,7 @@ static int udf_read_inode(struct inode *inode, bool hidden_inode) ret = -EIO; goto out; } + iinfo->i_hidden = hidden_inode; iinfo->i_unique = 0; iinfo->i_lenEAttr = 0; iinfo->i_lenExtents = 0; @@ -1636,8 +1637,12 @@ static int udf_update_inode(struct inode *inode, int do_sync) if (S_ISDIR(inode->i_mode) && inode->i_nlink > 0) fe->fileLinkCount = cpu_to_le16(inode->i_nlink - 1); - else - fe->fileLinkCount = cpu_to_le16(inode->i_nlink); + else { + if (iinfo->i_hidden) + fe->fileLinkCount = cpu_to_le16(0); + else + fe->fileLinkCount = cpu_to_le16(inode->i_nlink); + } fe->informationLength = cpu_to_le64(inode->i_size); diff --git a/fs/udf/super.c b/fs/udf/super.c index 06eda8177b5f..241b40e886b3 100644 --- a/fs/udf/super.c +++ b/fs/udf/super.c @@ -147,6 +147,7 @@ static struct inode *udf_alloc_inode(struct super_block *sb) ei->i_next_alloc_goal = 0; ei->i_strat4096 = 0; ei->i_streamdir = 0; + ei->i_hidden = 0; init_rwsem(&ei->i_data_sem); ei->cached_extent.lstart = -1; spin_lock_init(&ei->i_extent_cache_lock); diff --git a/fs/udf/udf_i.h b/fs/udf/udf_i.h index 06ff7006b822..312b7c9ef10e 100644 --- a/fs/udf/udf_i.h +++ b/fs/udf/udf_i.h @@ -44,7 +44,8 @@ struct udf_inode_info { unsigned i_use : 1; /* unallocSpaceEntry */ unsigned i_strat4096 : 1; unsigned i_streamdir : 1; - unsigned reserved : 25; + unsigned i_hidden : 1; /* hidden system inode */ + unsigned reserved : 24; __u8 *i_data; struct kernel_lb_addr i_locStreamdir; __u64 i_lenStreams;

1 year, 10 months

1
0
0 0

FAILED: patch "[PATCH] udf: Preserve link count of system files" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x fc8033a34a3ca7d23353e645e6dde5d364ac5f12 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '167810995913998(a)kroah.com' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: fc8033a34a3c ("udf: Preserve link count of system files") 382a2287bf9c ("udf: Remove pointless union in udf_inode_info") 044e2e26f214 ("udf: Avoid accessing uninitialized data on failed inode read") ab9a3a737284 ("udf: reduce leakage of blocks related to named streams") d288d95842f1 ("udf: Fix BUG on corrupted inode") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From fc8033a34a3ca7d23353e645e6dde5d364ac5f12 Mon Sep 17 00:00:00 2001 From: Jan Kara <jack(a)suse.cz> Date: Tue, 3 Jan 2023 09:56:56 +0100 Subject: [PATCH] udf: Preserve link count of system files System files in UDF filesystem have link count 0. To not confuse VFS we fudge the link count to be 1 when reading such inodes however we forget to restore the link count of 0 when writing such inodes. Fix that. CC: stable(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> diff --git a/fs/udf/inode.c b/fs/udf/inode.c index 31965c3798f2..9ee269d3d546 100644 --- a/fs/udf/inode.c +++ b/fs/udf/inode.c @@ -1301,6 +1301,7 @@ static int udf_read_inode(struct inode *inode, bool hidden_inode) ret = -EIO; goto out; } + iinfo->i_hidden = hidden_inode; iinfo->i_unique = 0; iinfo->i_lenEAttr = 0; iinfo->i_lenExtents = 0; @@ -1636,8 +1637,12 @@ static int udf_update_inode(struct inode *inode, int do_sync) if (S_ISDIR(inode->i_mode) && inode->i_nlink > 0) fe->fileLinkCount = cpu_to_le16(inode->i_nlink - 1); - else - fe->fileLinkCount = cpu_to_le16(inode->i_nlink); + else { + if (iinfo->i_hidden) + fe->fileLinkCount = cpu_to_le16(0); + else + fe->fileLinkCount = cpu_to_le16(inode->i_nlink); + } fe->informationLength = cpu_to_le64(inode->i_size); diff --git a/fs/udf/super.c b/fs/udf/super.c index 06eda8177b5f..241b40e886b3 100644 --- a/fs/udf/super.c +++ b/fs/udf/super.c @@ -147,6 +147,7 @@ static struct inode *udf_alloc_inode(struct super_block *sb) ei->i_next_alloc_goal = 0; ei->i_strat4096 = 0; ei->i_streamdir = 0; + ei->i_hidden = 0; init_rwsem(&ei->i_data_sem); ei->cached_extent.lstart = -1; spin_lock_init(&ei->i_extent_cache_lock); diff --git a/fs/udf/udf_i.h b/fs/udf/udf_i.h index 06ff7006b822..312b7c9ef10e 100644 --- a/fs/udf/udf_i.h +++ b/fs/udf/udf_i.h @@ -44,7 +44,8 @@ struct udf_inode_info { unsigned i_use : 1; /* unallocSpaceEntry */ unsigned i_strat4096 : 1; unsigned i_streamdir : 1; - unsigned reserved : 25; + unsigned i_hidden : 1; /* hidden system inode */ + unsigned reserved : 24; __u8 *i_data; struct kernel_lb_addr i_locStreamdir; __u64 i_lenStreams;

1 year, 10 months

1
0
0 0

FAILED: patch "[PATCH] f2fs: fix cgroup writeback accounting with fs-layer" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x 844545c51a5b2a524b22a2fe9d0b353b827d24b4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '1678109703254217(a)kroah.com' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 844545c51a5b ("f2fs: fix cgroup writeback accounting with fs-layer encryption") 9637d517347e ("Merge tag 'for-linus-20190715' of git://git.kernel.dk/linux-block") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 844545c51a5b2a524b22a2fe9d0b353b827d24b4 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Thu, 2 Feb 2023 17:02:39 -0800 Subject: [PATCH] f2fs: fix cgroup writeback accounting with fs-layer encryption When writing a page from an encrypted file that is using filesystem-layer encryption (not inline encryption), f2fs encrypts the pagecache page into a bounce page, then writes the bounce page. It also passes the bounce page to wbc_account_cgroup_owner(). That's incorrect, because the bounce page is a newly allocated temporary page that doesn't have the memory cgroup of the original pagecache page. This makes wbc_account_cgroup_owner() not account the I/O to the owner of the pagecache page as it should. Fix this by always passing the pagecache page to wbc_account_cgroup_owner(). Fixes: 578c647879f7 ("f2fs: implement cgroup writeback support") Cc: stable(a)vger.kernel.org Reported-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Acked-by: Tejun Heo <tj(a)kernel.org> Reviewed-by: Chao Yu <chao(a)kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 754841bce389..8a636500db0e 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -739,7 +739,7 @@ int f2fs_submit_page_bio(struct f2fs_io_info *fio) } if (fio->io_wbc && !is_read_io(fio->op)) - wbc_account_cgroup_owner(fio->io_wbc, page, PAGE_SIZE); + wbc_account_cgroup_owner(fio->io_wbc, fio->page, PAGE_SIZE); inc_page_count(fio->sbi, is_read_io(fio->op) ? __read_io_type(page) : WB_DATA_TYPE(fio->page)); @@ -949,7 +949,7 @@ int f2fs_merge_page_bio(struct f2fs_io_info *fio) } if (fio->io_wbc) - wbc_account_cgroup_owner(fio->io_wbc, page, PAGE_SIZE); + wbc_account_cgroup_owner(fio->io_wbc, fio->page, PAGE_SIZE); inc_page_count(fio->sbi, WB_DATA_TYPE(page)); @@ -1023,7 +1023,7 @@ void f2fs_submit_page_write(struct f2fs_io_info *fio) } if (fio->io_wbc) - wbc_account_cgroup_owner(fio->io_wbc, bio_page, PAGE_SIZE); + wbc_account_cgroup_owner(fio->io_wbc, fio->page, PAGE_SIZE); io->last_block_in_bio = fio->new_blkaddr;

1 year, 10 months

1
0
0 0

FAILED: patch "[PATCH] fs: dlm: fix race setting stop tx flag" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 164272113b685927126c938b4a9cbd2075eb15ee # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '16781096071167(a)kroah.com' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 164272113b68 ("fs: dlm: fix race setting stop tx flag") e01c4b7bd415 ("fd: dlm: trace send/recv of dlm message and rcom") 00e99ccde757 ("dlm: use __le types for dlm messages") 2f9dbeda8dc0 ("dlm: use __le types for rcom messages") 3428785a65da ("dlm: use __le types for dlm header") a8449f232ee3 ("dlm: add __CHECKER__ for false positives") 6c2e3bf68f3e ("fs: dlm: filter user dlm messages for kernel locks") 9af5b8f0ead7 ("fs: dlm: add debugfs rawmsg send functionality") 92732376fd29 ("fs: dlm: trace socket handling") f1d3b8f91d96 ("fs: dlm: initial support for tracepoints") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 164272113b685927126c938b4a9cbd2075eb15ee Mon Sep 17 00:00:00 2001 From: Alexander Aring <aahringo(a)redhat.com> Date: Thu, 12 Jan 2023 17:10:34 -0500 Subject: [PATCH] fs: dlm: fix race setting stop tx flag This patch sets the stop tx flag before we commit the dlm message. This flag will report about unexpected transmissions after we send the DLM_FIN message out, which should be the last message sent. When we commit the dlm fin message, it could be that we already got an ack back and the CLOSED state change already happened. We should not set this flag when we are in CLOSED state. To avoid this race we simply set the tx flag before the state change can be in progress by moving it before dlm_midcomms_commit_mhandle(). Cc: stable(a)vger.kernel.org Fixes: 489d8e559c65 ("fs: dlm: add reliable connection if reconnect") Signed-off-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: David Teigland <teigland(a)redhat.com> diff --git a/fs/dlm/midcomms.c b/fs/dlm/midcomms.c index a3eb19c8cec5..9d459d5bf800 100644 --- a/fs/dlm/midcomms.c +++ b/fs/dlm/midcomms.c @@ -406,6 +406,7 @@ static int dlm_send_fin(struct midcomms_node *node, if (!mh) return -ENOMEM; + set_bit(DLM_NODE_FLAG_STOP_TX, &node->flags); mh->ack_rcv = ack_rcv; m_header = (struct dlm_header *)ppc; @@ -417,7 +418,6 @@ static int dlm_send_fin(struct midcomms_node *node, pr_debug("sending fin msg to node %d\n", node->nodeid); dlm_midcomms_commit_mhandle(mh, NULL, 0); - set_bit(DLM_NODE_FLAG_STOP_TX, &node->flags); return 0; }

1 year, 10 months

1
0
0 0

FAILED: patch "[PATCH] fs: dlm: fix race setting stop tx flag" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 164272113b685927126c938b4a9cbd2075eb15ee # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '167810960625226(a)kroah.com' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 164272113b68 ("fs: dlm: fix race setting stop tx flag") e01c4b7bd415 ("fd: dlm: trace send/recv of dlm message and rcom") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 164272113b685927126c938b4a9cbd2075eb15ee Mon Sep 17 00:00:00 2001 From: Alexander Aring <aahringo(a)redhat.com> Date: Thu, 12 Jan 2023 17:10:34 -0500 Subject: [PATCH] fs: dlm: fix race setting stop tx flag This patch sets the stop tx flag before we commit the dlm message. This flag will report about unexpected transmissions after we send the DLM_FIN message out, which should be the last message sent. When we commit the dlm fin message, it could be that we already got an ack back and the CLOSED state change already happened. We should not set this flag when we are in CLOSED state. To avoid this race we simply set the tx flag before the state change can be in progress by moving it before dlm_midcomms_commit_mhandle(). Cc: stable(a)vger.kernel.org Fixes: 489d8e559c65 ("fs: dlm: add reliable connection if reconnect") Signed-off-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: David Teigland <teigland(a)redhat.com> diff --git a/fs/dlm/midcomms.c b/fs/dlm/midcomms.c index a3eb19c8cec5..9d459d5bf800 100644 --- a/fs/dlm/midcomms.c +++ b/fs/dlm/midcomms.c @@ -406,6 +406,7 @@ static int dlm_send_fin(struct midcomms_node *node, if (!mh) return -ENOMEM; + set_bit(DLM_NODE_FLAG_STOP_TX, &node->flags); mh->ack_rcv = ack_rcv; m_header = (struct dlm_header *)ppc; @@ -417,7 +418,6 @@ static int dlm_send_fin(struct midcomms_node *node, pr_debug("sending fin msg to node %d\n", node->nodeid); dlm_midcomms_commit_mhandle(mh, NULL, 0); - set_bit(DLM_NODE_FLAG_STOP_TX, &node->flags); return 0; }

1 year, 10 months

1
0
0 0

FAILED: patch "[PATCH] fs: dlm: be sure to call dlm_send_queue_flush()" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 7354fa4ef697191effedc2ae9a8293427708bbf5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '16781095928214(a)kroah.com' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 7354fa4ef697 ("fs: dlm: be sure to call dlm_send_queue_flush()") 775af207464b ("fs: dlm: use WARN_ON_ONCE() instead of WARN_ON()") e01c4b7bd415 ("fd: dlm: trace send/recv of dlm message and rcom") 00e99ccde757 ("dlm: use __le types for dlm messages") 2f9dbeda8dc0 ("dlm: use __le types for rcom messages") 3428785a65da ("dlm: use __le types for dlm header") a8449f232ee3 ("dlm: add __CHECKER__ for false positives") 6c547f264077 ("fs: dlm: memory cache for midcomms hotpath") 6c2e3bf68f3e ("fs: dlm: filter user dlm messages for kernel locks") 9af5b8f0ead7 ("fs: dlm: add debugfs rawmsg send functionality") 92732376fd29 ("fs: dlm: trace socket handling") f1d3b8f91d96 ("fs: dlm: initial support for tracepoints") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7354fa4ef697191effedc2ae9a8293427708bbf5 Mon Sep 17 00:00:00 2001 From: Alexander Aring <aahringo(a)redhat.com> Date: Thu, 12 Jan 2023 17:10:33 -0500 Subject: [PATCH] fs: dlm: be sure to call dlm_send_queue_flush() If we release a midcomms node structure, there should be nothing left inside the dlm midcomms send queue. However, sometimes this is not true because I believe some DLM_FIN message was not acked... if we run into a shutdown timeout, then we should be sure there is no pending send dlm message inside this queue when releasing midcomms node structure. Cc: stable(a)vger.kernel.org Fixes: 489d8e559c65 ("fs: dlm: add reliable connection if reconnect") Signed-off-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: David Teigland <teigland(a)redhat.com> diff --git a/fs/dlm/midcomms.c b/fs/dlm/midcomms.c index 2e60d9a2c883..a3eb19c8cec5 100644 --- a/fs/dlm/midcomms.c +++ b/fs/dlm/midcomms.c @@ -1402,6 +1402,7 @@ static void midcomms_node_release(struct rcu_head *rcu) struct midcomms_node *node = container_of(rcu, struct midcomms_node, rcu); WARN_ON_ONCE(atomic_read(&node->send_queue_cnt)); + dlm_send_queue_flush(node); kfree(node); }

1 year, 10 months

1
0
0 0

FAILED: patch "[PATCH] fs: dlm: be sure to call dlm_send_queue_flush()" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 7354fa4ef697191effedc2ae9a8293427708bbf5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '16781095911850(a)kroah.com' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 7354fa4ef697 ("fs: dlm: be sure to call dlm_send_queue_flush()") 775af207464b ("fs: dlm: use WARN_ON_ONCE() instead of WARN_ON()") e01c4b7bd415 ("fd: dlm: trace send/recv of dlm message and rcom") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 7354fa4ef697191effedc2ae9a8293427708bbf5 Mon Sep 17 00:00:00 2001 From: Alexander Aring <aahringo(a)redhat.com> Date: Thu, 12 Jan 2023 17:10:33 -0500 Subject: [PATCH] fs: dlm: be sure to call dlm_send_queue_flush() If we release a midcomms node structure, there should be nothing left inside the dlm midcomms send queue. However, sometimes this is not true because I believe some DLM_FIN message was not acked... if we run into a shutdown timeout, then we should be sure there is no pending send dlm message inside this queue when releasing midcomms node structure. Cc: stable(a)vger.kernel.org Fixes: 489d8e559c65 ("fs: dlm: add reliable connection if reconnect") Signed-off-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: David Teigland <teigland(a)redhat.com> diff --git a/fs/dlm/midcomms.c b/fs/dlm/midcomms.c index 2e60d9a2c883..a3eb19c8cec5 100644 --- a/fs/dlm/midcomms.c +++ b/fs/dlm/midcomms.c @@ -1402,6 +1402,7 @@ static void midcomms_node_release(struct rcu_head *rcu) struct midcomms_node *node = container_of(rcu, struct midcomms_node, rcu); WARN_ON_ONCE(atomic_read(&node->send_queue_cnt)); + dlm_send_queue_flush(node); kfree(node); }

1 year, 10 months

1
0
0 0

FAILED: patch "[PATCH] fs: dlm: fix use after free in midcomms commit" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 724b6bab0d75f1dc01fdfbf7fe8d4217a5cb90ba # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '16781095834451(a)kroah.com' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 724b6bab0d75 ("fs: dlm: fix use after free in midcomms commit") e01c4b7bd415 ("fd: dlm: trace send/recv of dlm message and rcom") 00e99ccde757 ("dlm: use __le types for dlm messages") 2f9dbeda8dc0 ("dlm: use __le types for rcom messages") 3428785a65da ("dlm: use __le types for dlm header") a8449f232ee3 ("dlm: add __CHECKER__ for false positives") 6c2e3bf68f3e ("fs: dlm: filter user dlm messages for kernel locks") 9af5b8f0ead7 ("fs: dlm: add debugfs rawmsg send functionality") 92732376fd29 ("fs: dlm: trace socket handling") f1d3b8f91d96 ("fs: dlm: initial support for tracepoints") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 724b6bab0d75f1dc01fdfbf7fe8d4217a5cb90ba Mon Sep 17 00:00:00 2001 From: Alexander Aring <aahringo(a)redhat.com> Date: Thu, 12 Jan 2023 17:10:32 -0500 Subject: [PATCH] fs: dlm: fix use after free in midcomms commit While working on processing dlm message in softirq context I experienced the following KASAN use-after-free warning: [ 151.760477] ================================================================== [ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347 [ 151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828 [ 151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014 [ 151.768726] Call Trace: [ 151.769277] <TASK> [ 151.769748] dump_stack_lvl+0x5b/0x86 [ 151.770556] print_report+0x180/0x4c8 [ 151.771378] ? kasan_complete_mode_report_info+0x7c/0x1e0 [ 151.772241] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.773069] kasan_report+0x93/0x1a0 [ 151.773668] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.774514] __asan_load4+0x7e/0xa0 [ 151.775089] dlm_midcomms_commit_mhandle+0x19d/0x4b0 [ 151.775890] ? create_message.isra.29.constprop.64+0x57/0xc0 [ 151.776770] send_common+0x19f/0x1b0 [ 151.777342] ? remove_from_waiters+0x60/0x60 [ 151.778017] ? lock_downgrade+0x410/0x410 [ 151.778648] ? __this_cpu_preempt_check+0x13/0x20 [ 151.779421] ? rcu_lockdep_current_cpu_online+0x88/0xc0 [ 151.780292] _convert_lock+0x46/0x150 [ 151.780893] convert_lock+0x7b/0xc0 [ 151.781459] dlm_lock+0x3ac/0x580 [ 151.781993] ? 0xffffffffc0540000 [ 151.782522] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.783379] ? dlm_scan_rsbs+0xa70/0xa70 [ 151.784003] ? preempt_count_sub+0xd6/0x130 [ 151.784661] ? is_module_address+0x47/0x70 [ 151.785309] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.786166] ? 0xffffffffc0540000 [ 151.786693] ? lockdep_init_map_type+0xc3/0x360 [ 151.787414] ? 0xffffffffc0540000 [ 151.787947] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.789004] ? torture_stop+0x120/0x120 [dlm_locktorture] [ 151.789858] ? 0xffffffffc0540000 [ 151.790392] ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture] [ 151.791347] ? delay_tsc+0x94/0xc0 [ 151.791898] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.792735] ? torture_start+0x30/0x30 [dlm_locktorture] [ 151.793606] lock_torture+0x177/0x270 [dlm_locktorture] [ 151.794448] ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture] [ 151.795539] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.796476] ? do_raw_spin_lock+0x11e/0x1e0 [ 151.797152] ? mark_held_locks+0x34/0xb0 [ 151.797784] ? _raw_spin_unlock_irqrestore+0x30/0x70 [ 151.798581] ? __kthread_parkme+0x79/0x110 [ 151.799246] ? trace_preempt_on+0x2a/0xf0 [ 151.799902] ? __kthread_parkme+0x79/0x110 [ 151.800579] ? preempt_count_sub+0xd6/0x130 [ 151.801271] ? __kasan_check_read+0x11/0x20 [ 151.801963] ? __kthread_parkme+0xec/0x110 [ 151.802630] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 151.803569] kthread+0x192/0x1d0 [ 151.804104] ? kthread_complete_and_exit+0x30/0x30 [ 151.804881] ret_from_fork+0x1f/0x30 [ 151.805480] </TASK> [ 151.806111] Allocated by task 1347: [ 151.806681] kasan_save_stack+0x26/0x50 [ 151.807308] kasan_set_track+0x25/0x30 [ 151.807920] kasan_save_alloc_info+0x1e/0x30 [ 151.808609] __kasan_slab_alloc+0x63/0x80 [ 151.809263] kmem_cache_alloc+0x1ad/0x830 [ 151.809916] dlm_allocate_mhandle+0x17/0x20 [ 151.810590] dlm_midcomms_get_mhandle+0x96/0x260 [ 151.811344] _create_message+0x95/0x180 [ 151.811994] create_message.isra.29.constprop.64+0x57/0xc0 [ 151.812880] send_common+0x129/0x1b0 [ 151.813467] _convert_lock+0x46/0x150 [ 151.814074] convert_lock+0x7b/0xc0 [ 151.814648] dlm_lock+0x3ac/0x580 [ 151.815199] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture] [ 151.816258] torture_ex_iter+0xc3/0xea [dlm_locktorture] [ 151.817129] lock_torture+0x177/0x270 [dlm_locktorture] [ 151.817986] kthread+0x192/0x1d0 [ 151.818518] ret_from_fork+0x1f/0x30 [ 151.819369] Freed by task 1336: [ 151.819890] kasan_save_stack+0x26/0x50 [ 151.820514] kasan_set_track+0x25/0x30 [ 151.821128] kasan_save_free_info+0x2e/0x50 [ 151.821812] __kasan_slab_free+0x107/0x1a0 [ 151.822483] kmem_cache_free+0x204/0x5e0 [ 151.823152] dlm_free_mhandle+0x18/0x20 [ 151.823781] dlm_mhandle_release+0x2e/0x40 [ 151.824454] rcu_core+0x583/0x1330 [ 151.825047] rcu_core_si+0xe/0x20 [ 151.825594] __do_softirq+0xf4/0x5c2 [ 151.826450] Last potentially related work creation: [ 151.827238] kasan_save_stack+0x26/0x50 [ 151.827870] __kasan_record_aux_stack+0xa2/0xc0 [ 151.828609] kasan_record_aux_stack_noalloc+0xb/0x20 [ 151.829415] call_rcu+0x4c/0x760 [ 151.829954] dlm_mhandle_delete+0x97/0xb0 [ 151.830718] dlm_process_incoming_buffer+0x2fc/0xb30 [ 151.831524] process_dlm_messages+0x16e/0x470 [ 151.832245] process_one_work+0x505/0xa10 [ 151.832905] worker_thread+0x67/0x650 [ 151.833507] kthread+0x192/0x1d0 [ 151.834046] ret_from_fork+0x1f/0x30 [ 151.834900] The buggy address belongs to the object at ffff88811a980c30 which belongs to the cache dlm_mhandle of size 88 [ 151.836894] The buggy address is located 48 bytes inside of 88-byte region [ffff88811a980c30, ffff88811a980c88) [ 151.839007] The buggy address belongs to the physical page: [ 151.839904] page:0000000076cf5d62 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11a980 [ 151.841378] flags: 0x8000000000000200(slab|zone=2) [ 151.842141] raw: 8000000000000200 0000000000000000 dead000000000122 ffff8881089b43c0 [ 151.843401] raw: 0000000000000000 0000000000220022 00000001ffffffff 0000000000000000 [ 151.844640] page dumped because: kasan: bad access detected [ 151.845822] Memory state around the buggy address: [ 151.846602] ffff88811a980b00: fb fb fb fb fc fc fc fc fa fb fb fb fb fb fb fb [ 151.847761] ffff88811a980b80: fb fb fb fc fc fc fc fa fb fb fb fb fb fb fb fb [ 151.848921] >ffff88811a980c00: fb fb fc fc fc fc fa fb fb fb fb fb fb fb fb fb [ 151.850076] ^ [ 151.851085] ffff88811a980c80: fb fc fc fc fc fa fb fb fb fb fb fb fb fb fb fb [ 151.852269] ffff88811a980d00: fc fc fc fc fa fb fb fb fb fb fb fb fb fb fb fc [ 151.853428] ================================================================== [ 151.855618] Disabling lock debugging due to kernel taint It is accessing a mhandle in dlm_midcomms_commit_mhandle() and the mhandle was freed by a call_rcu() call in dlm_process_incoming_buffer(), dlm_mhandle_delete(). It looks like it was freed because an ack of this message was received. There is a short race between committing the dlm message to be transmitted and getting an ack back. If the ack is faster than returning from dlm_midcomms_commit_msg_3_2(), then we run into a use-after free because we still need to reference the mhandle when calling srcu_read_unlock(). To avoid that, we don't allow that mhandle to be freed between dlm_midcomms_commit_msg_3_2() and srcu_read_unlock() by using rcu read lock. We can do that because mhandle is protected by rcu handling. Cc: stable(a)vger.kernel.org Fixes: 489d8e559c65 ("fs: dlm: add reliable connection if reconnect") Signed-off-by: Alexander Aring <aahringo(a)redhat.com> Signed-off-by: David Teigland <teigland(a)redhat.com> diff --git a/fs/dlm/midcomms.c b/fs/dlm/midcomms.c index fc015a6abe17..2e60d9a2c883 100644 --- a/fs/dlm/midcomms.c +++ b/fs/dlm/midcomms.c @@ -1214,8 +1214,15 @@ void dlm_midcomms_commit_mhandle(struct dlm_mhandle *mh, dlm_free_mhandle(mh); break; case DLM_VERSION_3_2: + /* held rcu read lock here, because we sending the + * dlm message out, when we do that we could receive + * an ack back which releases the mhandle and we + * get a use after free. + */ + rcu_read_lock(); dlm_midcomms_commit_msg_3_2(mh, name, namelen); srcu_read_unlock(&nodes_srcu, mh->idx); + rcu_read_unlock(); break; default: srcu_read_unlock(&nodes_srcu, mh->idx);

1 year, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2023