July 2024 - Linux-stable-mirror

stable backport: wifi: mac80211: track capability/opmode NSS separately

by Hauke Mehrtens

Hi, Please backport the following patch back to the stable series 6.6 and 6.1: commit a8bca3e9371dc5e276af4168be099b2a05554c2a Author: Johannes Berg <johannes.berg(a)intel.com> Date: Wed Feb 28 12:01:57 2024 +0100 wifi: mac80211: track capability/opmode NSS separately There is a small conflict in the copyright year update in net/mac80211/sta_info.h, just take the 2024 version. On kernel 6.1 please backport this patch first to make the other one apply: commit 57b341e9ab13e5688491bfd54f8b5502416c8905 Author: Rameshkumar Sundaram <quic_ramess(a)quicinc.com> Date: Tue Feb 7 17:11:46 2023 +0530 wifi: mac80211: Allow NSS change only up to capability This commit fixes a throughput regression introduced into Linux stable with the backport of following commit: commit dd6c064cfc3fc18d871107c6f5db8837e88572e4 Author: Johannes Berg <johannes.berg(a)intel.com> Date: Mon Jan 29 15:53:55 2024 +0100 wifi: mac80211: set station RX-NSS on reconfig On older kernel versions it is harder to backport the fixes, maybe revert the offending commit in Linux stable 5.15 and older. This regression was found by multiple users of OpenWrt in Wifi AP mode. See the discussion in this forum thread: https://forum.openwrt.org/t/openwrt-23-05-4-service-release/204514/111 Thank you KONG from the OpenWrt forum for finding the commit which reduced the Wifi throughput. Hauke

3 months, 1 week

2
1
0 0

[tip: sched/core] sched/cputime: Fix mul_u64_u64_div_u64() precision for cputime

by tip-bot2 for Zheng Zucheng

The following commit has been merged into the sched/core branch of tip: Commit-ID: 77baa5bafcbe1b2a15ef9c37232c21279c95481c Gitweb: https://git.kernel.org/tip/77baa5bafcbe1b2a15ef9c37232c21279c95481c Author: Zheng Zucheng <zhengzucheng(a)huawei.com> AuthorDate: Fri, 26 Jul 2024 02:32:35 Committer: Peter Zijlstra <peterz(a)infradead.org> CommitterDate: Mon, 29 Jul 2024 12:22:32 +02:00 sched/cputime: Fix mul_u64_u64_div_u64() precision for cputime In extreme test scenarios: the 14th field utime in /proc/xx/stat is greater than sum_exec_runtime, utime = 18446744073709518790 ns, rtime = 135989749728000 ns In cputime_adjust() process, stime is greater than rtime due to mul_u64_u64_div_u64() precision problem. before call mul_u64_u64_div_u64(), stime = 175136586720000, rtime = 135989749728000, utime = 1416780000. after call mul_u64_u64_div_u64(), stime = 135989949653530 unsigned reversion occurs because rtime is less than stime. utime = rtime - stime = 135989749728000 - 135989949653530 = -199925530 = (u64)18446744073709518790 Trigger condition: 1). User task run in kernel mode most of time 2). ARM64 architecture 3). TICK_CPU_ACCOUNTING=y CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set Fix mul_u64_u64_div_u64() conversion precision by reset stime to rtime Fixes: 3dc167ba5729 ("sched/cputime: Improve cputime_adjust()") Signed-off-by: Zheng Zucheng <zhengzucheng(a)huawei.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: <stable(a)vger.kernel.org> Link: https://lkml.kernel.org/r/20240726023235.217771-1-zhengzucheng@huawei.com --- kernel/sched/cputime.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c index a5e0029..0bed0fa 100644 --- a/kernel/sched/cputime.c +++ b/kernel/sched/cputime.c @@ -582,6 +582,12 @@ void cputime_adjust(struct task_cputime *curr, struct prev_cputime *prev, } stime = mul_u64_u64_div_u64(stime, rtime, stime + utime); + /* + * Because mul_u64_u64_div_u64() can approximate on some + * achitectures; enforce the constraint that: a*b/(b+c) <= a. + */ + if (unlikely(stime > rtime)) + stime = rtime; update: /*

3 months, 1 week

1
0
0 0

[PATCH V7 1/9] sched/deadline: Comment sched_dl_entity::dl_server variable

by Daniel Bristot de Oliveira

Add an explanation for the newly added variable. Cc: stable(a)vger.kernel.org Fixes: 63ba8422f876 ("sched/deadline: Introduce deadline servers") Signed-off-by: Daniel Bristot de Oliveira <bristot(a)kernel.org> --- include/linux/sched.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/sched.h b/include/linux/sched.h index 61591ac6eab6..abce356932cc 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -637,6 +637,8 @@ struct sched_dl_entity { * * @dl_overrun tells if the task asked to be informed about runtime * overruns. + * + * @dl_server tells if this is a server entity. */ unsigned int dl_throttled : 1; unsigned int dl_yielded : 1; -- 2.45.1

3 months, 1 week

2
1
0 0

[PATCH V7 2/9] sched/core: Add clearing of ->dl_server in put_prev_task_balance()

by Daniel Bristot de Oliveira

From: "Joel Fernandes (Google)" <joel(a)joelfernandes.org> Paths using put_prev_task_balance() need to do a pick shortly after. Make sure they also clear the ->dl_server on prev as a part of that. Cc: stable(a)vger.kernel.org Fixes: 63ba8422f876 ("sched/deadline: Introduce deadline servers") Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org> Signed-off-by: Daniel Bristot de Oliveira <bristot(a)kernel.org> --- kernel/sched/core.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index bcf2c4cc0522..08c409457152 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6006,6 +6006,14 @@ static void put_prev_task_balance(struct rq *rq, struct task_struct *prev, #endif put_prev_task(rq, prev); + + /* + * We've updated @prev and no longer need the server link, clear it. + * Must be done before ->pick_next_task() because that can (re)set + * ->dl_server. + */ + if (prev->dl_server) + prev->dl_server = NULL; } /* @@ -6049,14 +6057,6 @@ __pick_next_task(struct rq *rq, struct task_struct *prev, struct rq_flags *rf) restart: put_prev_task_balance(rq, prev, rf); - /* - * We've updated @prev and no longer need the server link, clear it. - * Must be done before ->pick_next_task() because that can (re)set - * ->dl_server. - */ - if (prev->dl_server) - prev->dl_server = NULL; - for_each_class(class) { p = class->pick_next_task(rq); if (p) -- 2.45.1

3 months, 1 week

2
1
0 0

[PATCH V7 3/9] sched/core: Clear prev->dl_server in CFS pick fast path

by Daniel Bristot de Oliveira

From: Youssef Esmat <youssefesmat(a)google.com> In case the previous pick was a DL server pick, ->dl_server might be set. Clear it in the fast path as well. Cc: stable(a)vger.kernel.org Fixes: 63ba8422f876 ("sched/deadline: Introduce deadline servers") Signed-off-by: Youssef Esmat <youssefesmat(a)google.com> Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org> Signed-off-by: Daniel Bristot de Oliveira <bristot(a)kernel.org> --- kernel/sched/core.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 08c409457152..6d01863f93ca 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6044,6 +6044,13 @@ __pick_next_task(struct rq *rq, struct task_struct *prev, struct rq_flags *rf) p = pick_next_task_idle(rq); } + /* + * This is a normal CFS pick, but the previous could be a DL pick. + * Clear it as previous is no longer picked. + */ + if (prev->dl_server) + prev->dl_server = NULL; + /* * This is the fast path; it cannot be a DL server pick; * therefore even if @p == @prev, ->dl_server must be NULL. -- 2.45.1

3 months, 1 week

2
1
0 0

FAILED: patch "[PATCH] ext4: check the extent status again before inserting delalloc" 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 0ea6560abb3bac1ffcfa4bf6b2c4d344fdc27b3c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024072911-elsewhere-latter-afa3@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 0ea6560abb3b ("ext4: check the extent status again before inserting delalloc block") acf795dc161f ("ext4: convert to exclusive lock while inserting delalloc extents") 3fcc2b887a1b ("ext4: refactor ext4_da_map_blocks()") 6c120399cde6 ("ext4: make ext4_es_insert_extent() return void") 2a69c450083d ("ext4: using nofail preallocation in ext4_es_insert_extent()") bda3efaf774f ("ext4: use pre-allocated es in __es_remove_extent()") 95f0b320339a ("ext4: use pre-allocated es in __es_insert_extent()") 73a2f033656b ("ext4: factor out __es_alloc_extent() and __es_free_extent()") 9649eb18c628 ("ext4: add a new helper to check if es must be kept") 8016e29f4362 ("ext4: fast commit recovery path") 5b849b5f96b4 ("jbd2: fast commit recovery path") aa75f4d3daae ("ext4: main fast-commit commit path") ff780b91efe9 ("jbd2: add fast commit machinery") 6866d7b3f2bb ("ext4 / jbd2: add fast commit initialization") 995a3ed67fc8 ("ext4: add fast_commit feature and handling for extended mount options") 2d069c0889ef ("ext4: use common helpers in all places reading metadata buffers") d9befedaafcf ("ext4: clear buffer verified flag if read meta block from disk") 15ed2851b0f4 ("ext4: remove unused argument from ext4_(inc|dec)_count") 3d392b2676bf ("ext4: add prefetch_block_bitmaps mount option") ab74c7b23f37 ("ext4: indicate via a block bitmap read is prefetched via a tracepoint") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0ea6560abb3bac1ffcfa4bf6b2c4d344fdc27b3c Mon Sep 17 00:00:00 2001 From: Zhang Yi <yi.zhang(a)huawei.com> Date: Fri, 17 May 2024 20:39:57 +0800 Subject: [PATCH] ext4: check the extent status again before inserting delalloc block ext4_da_map_blocks looks up for any extent entry in the extent status tree (w/o i_data_sem) and then the looks up for any ondisk extent mapping (with i_data_sem in read mode). If it finds a hole in the extent status tree or if it couldn't find any entry at all, it then takes the i_data_sem in write mode to add a da entry into the extent status tree. This can actually race with page mkwrite & fallocate path. Note that this is ok between 1. ext4 buffered-write path v/s ext4_page_mkwrite(), because of the folio lock 2. ext4 buffered write path v/s ext4 fallocate because of the inode lock. But this can race between ext4_page_mkwrite() & ext4 fallocate path ext4_page_mkwrite() ext4_fallocate() block_page_mkwrite() ext4_da_map_blocks() //find hole in extent status tree ext4_alloc_file_blocks() ext4_map_blocks() //allocate block and unwritten extent ext4_insert_delayed_block() ext4_da_reserve_space() //reserve one more block ext4_es_insert_delayed_block() //drop unwritten extent and add delayed extent by mistake Then, the delalloc extent is wrong until writeback and the extra reserved block can't be released any more and it triggers below warning: EXT4-fs (pmem2): Inode 13 (00000000bbbd4d23): i_reserved_data_blocks(1) not cleared! Fix the problem by looking up extent status tree again while the i_data_sem is held in write mode. If it still can't find any entry, then we insert a new da entry into the extent status tree. Cc: stable(a)vger.kernel.org Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Link: https://patch.msgid.link/20240517124005.347221-3-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 168819b4db01..4b0d64a76e88 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1737,6 +1737,7 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock, if (ext4_es_is_hole(&es)) goto add_delayed; +found: /* * Delayed extent could be allocated by fallocate. * So we need to check it. @@ -1781,6 +1782,26 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock, add_delayed: down_write(&EXT4_I(inode)->i_data_sem); + /* + * Page fault path (ext4_page_mkwrite does not take i_rwsem) + * and fallocate path (no folio lock) can race. Make sure we + * lookup the extent status tree here again while i_data_sem + * is held in write mode, before inserting a new da entry in + * the extent status tree. + */ + if (ext4_es_lookup_extent(inode, iblock, NULL, &es)) { + if (!ext4_es_is_hole(&es)) { + up_write(&EXT4_I(inode)->i_data_sem); + goto found; + } + } else if (!ext4_has_inline_data(inode)) { + retval = ext4_map_query_blocks(NULL, inode, map); + if (retval) { + up_write(&EXT4_I(inode)->i_data_sem); + return retval; + } + } + retval = ext4_insert_delayed_block(inode, map->m_lblk); up_write(&EXT4_I(inode)->i_data_sem); if (retval)

3 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] ext4: check the extent status again before inserting delalloc" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x 0ea6560abb3bac1ffcfa4bf6b2c4d344fdc27b3c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024072909-shamrock-frail-43e9@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 0ea6560abb3b ("ext4: check the extent status again before inserting delalloc block") acf795dc161f ("ext4: convert to exclusive lock while inserting delalloc extents") 3fcc2b887a1b ("ext4: refactor ext4_da_map_blocks()") 6c120399cde6 ("ext4: make ext4_es_insert_extent() return void") 2a69c450083d ("ext4: using nofail preallocation in ext4_es_insert_extent()") bda3efaf774f ("ext4: use pre-allocated es in __es_remove_extent()") 95f0b320339a ("ext4: use pre-allocated es in __es_insert_extent()") 73a2f033656b ("ext4: factor out __es_alloc_extent() and __es_free_extent()") 9649eb18c628 ("ext4: add a new helper to check if es must be kept") 8016e29f4362 ("ext4: fast commit recovery path") 5b849b5f96b4 ("jbd2: fast commit recovery path") aa75f4d3daae ("ext4: main fast-commit commit path") ff780b91efe9 ("jbd2: add fast commit machinery") 6866d7b3f2bb ("ext4 / jbd2: add fast commit initialization") 995a3ed67fc8 ("ext4: add fast_commit feature and handling for extended mount options") 2d069c0889ef ("ext4: use common helpers in all places reading metadata buffers") d9befedaafcf ("ext4: clear buffer verified flag if read meta block from disk") 15ed2851b0f4 ("ext4: remove unused argument from ext4_(inc|dec)_count") 3d392b2676bf ("ext4: add prefetch_block_bitmaps mount option") ab74c7b23f37 ("ext4: indicate via a block bitmap read is prefetched via a tracepoint") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0ea6560abb3bac1ffcfa4bf6b2c4d344fdc27b3c Mon Sep 17 00:00:00 2001 From: Zhang Yi <yi.zhang(a)huawei.com> Date: Fri, 17 May 2024 20:39:57 +0800 Subject: [PATCH] ext4: check the extent status again before inserting delalloc block ext4_da_map_blocks looks up for any extent entry in the extent status tree (w/o i_data_sem) and then the looks up for any ondisk extent mapping (with i_data_sem in read mode). If it finds a hole in the extent status tree or if it couldn't find any entry at all, it then takes the i_data_sem in write mode to add a da entry into the extent status tree. This can actually race with page mkwrite & fallocate path. Note that this is ok between 1. ext4 buffered-write path v/s ext4_page_mkwrite(), because of the folio lock 2. ext4 buffered write path v/s ext4 fallocate because of the inode lock. But this can race between ext4_page_mkwrite() & ext4 fallocate path ext4_page_mkwrite() ext4_fallocate() block_page_mkwrite() ext4_da_map_blocks() //find hole in extent status tree ext4_alloc_file_blocks() ext4_map_blocks() //allocate block and unwritten extent ext4_insert_delayed_block() ext4_da_reserve_space() //reserve one more block ext4_es_insert_delayed_block() //drop unwritten extent and add delayed extent by mistake Then, the delalloc extent is wrong until writeback and the extra reserved block can't be released any more and it triggers below warning: EXT4-fs (pmem2): Inode 13 (00000000bbbd4d23): i_reserved_data_blocks(1) not cleared! Fix the problem by looking up extent status tree again while the i_data_sem is held in write mode. If it still can't find any entry, then we insert a new da entry into the extent status tree. Cc: stable(a)vger.kernel.org Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Link: https://patch.msgid.link/20240517124005.347221-3-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 168819b4db01..4b0d64a76e88 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1737,6 +1737,7 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock, if (ext4_es_is_hole(&es)) goto add_delayed; +found: /* * Delayed extent could be allocated by fallocate. * So we need to check it. @@ -1781,6 +1782,26 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock, add_delayed: down_write(&EXT4_I(inode)->i_data_sem); + /* + * Page fault path (ext4_page_mkwrite does not take i_rwsem) + * and fallocate path (no folio lock) can race. Make sure we + * lookup the extent status tree here again while i_data_sem + * is held in write mode, before inserting a new da entry in + * the extent status tree. + */ + if (ext4_es_lookup_extent(inode, iblock, NULL, &es)) { + if (!ext4_es_is_hole(&es)) { + up_write(&EXT4_I(inode)->i_data_sem); + goto found; + } + } else if (!ext4_has_inline_data(inode)) { + retval = ext4_map_query_blocks(NULL, inode, map); + if (retval) { + up_write(&EXT4_I(inode)->i_data_sem); + return retval; + } + } + retval = ext4_insert_delayed_block(inode, map->m_lblk); up_write(&EXT4_I(inode)->i_data_sem); if (retval)

3 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] ext4: check the extent status again before inserting delalloc" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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.10.y git checkout FETCH_HEAD git cherry-pick -x 0ea6560abb3bac1ffcfa4bf6b2c4d344fdc27b3c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024072908-ibuprofen-destruct-80dc@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 0ea6560abb3b ("ext4: check the extent status again before inserting delalloc block") acf795dc161f ("ext4: convert to exclusive lock while inserting delalloc extents") 3fcc2b887a1b ("ext4: refactor ext4_da_map_blocks()") 6c120399cde6 ("ext4: make ext4_es_insert_extent() return void") 2a69c450083d ("ext4: using nofail preallocation in ext4_es_insert_extent()") bda3efaf774f ("ext4: use pre-allocated es in __es_remove_extent()") 95f0b320339a ("ext4: use pre-allocated es in __es_insert_extent()") 73a2f033656b ("ext4: factor out __es_alloc_extent() and __es_free_extent()") 9649eb18c628 ("ext4: add a new helper to check if es must be kept") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0ea6560abb3bac1ffcfa4bf6b2c4d344fdc27b3c Mon Sep 17 00:00:00 2001 From: Zhang Yi <yi.zhang(a)huawei.com> Date: Fri, 17 May 2024 20:39:57 +0800 Subject: [PATCH] ext4: check the extent status again before inserting delalloc block ext4_da_map_blocks looks up for any extent entry in the extent status tree (w/o i_data_sem) and then the looks up for any ondisk extent mapping (with i_data_sem in read mode). If it finds a hole in the extent status tree or if it couldn't find any entry at all, it then takes the i_data_sem in write mode to add a da entry into the extent status tree. This can actually race with page mkwrite & fallocate path. Note that this is ok between 1. ext4 buffered-write path v/s ext4_page_mkwrite(), because of the folio lock 2. ext4 buffered write path v/s ext4 fallocate because of the inode lock. But this can race between ext4_page_mkwrite() & ext4 fallocate path ext4_page_mkwrite() ext4_fallocate() block_page_mkwrite() ext4_da_map_blocks() //find hole in extent status tree ext4_alloc_file_blocks() ext4_map_blocks() //allocate block and unwritten extent ext4_insert_delayed_block() ext4_da_reserve_space() //reserve one more block ext4_es_insert_delayed_block() //drop unwritten extent and add delayed extent by mistake Then, the delalloc extent is wrong until writeback and the extra reserved block can't be released any more and it triggers below warning: EXT4-fs (pmem2): Inode 13 (00000000bbbd4d23): i_reserved_data_blocks(1) not cleared! Fix the problem by looking up extent status tree again while the i_data_sem is held in write mode. If it still can't find any entry, then we insert a new da entry into the extent status tree. Cc: stable(a)vger.kernel.org Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Link: https://patch.msgid.link/20240517124005.347221-3-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 168819b4db01..4b0d64a76e88 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1737,6 +1737,7 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock, if (ext4_es_is_hole(&es)) goto add_delayed; +found: /* * Delayed extent could be allocated by fallocate. * So we need to check it. @@ -1781,6 +1782,26 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock, add_delayed: down_write(&EXT4_I(inode)->i_data_sem); + /* + * Page fault path (ext4_page_mkwrite does not take i_rwsem) + * and fallocate path (no folio lock) can race. Make sure we + * lookup the extent status tree here again while i_data_sem + * is held in write mode, before inserting a new da entry in + * the extent status tree. + */ + if (ext4_es_lookup_extent(inode, iblock, NULL, &es)) { + if (!ext4_es_is_hole(&es)) { + up_write(&EXT4_I(inode)->i_data_sem); + goto found; + } + } else if (!ext4_has_inline_data(inode)) { + retval = ext4_map_query_blocks(NULL, inode, map); + if (retval) { + up_write(&EXT4_I(inode)->i_data_sem); + return retval; + } + } + retval = ext4_insert_delayed_block(inode, map->m_lblk); up_write(&EXT4_I(inode)->i_data_sem); if (retval)

3 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] ext4: check the extent status again before inserting delalloc" 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 0ea6560abb3bac1ffcfa4bf6b2c4d344fdc27b3c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024072907-animosity-ocelot-8f7c@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 0ea6560abb3b ("ext4: check the extent status again before inserting delalloc block") acf795dc161f ("ext4: convert to exclusive lock while inserting delalloc extents") 3fcc2b887a1b ("ext4: refactor ext4_da_map_blocks()") 6c120399cde6 ("ext4: make ext4_es_insert_extent() return void") 2a69c450083d ("ext4: using nofail preallocation in ext4_es_insert_extent()") bda3efaf774f ("ext4: use pre-allocated es in __es_remove_extent()") 95f0b320339a ("ext4: use pre-allocated es in __es_insert_extent()") 73a2f033656b ("ext4: factor out __es_alloc_extent() and __es_free_extent()") 9649eb18c628 ("ext4: add a new helper to check if es must be kept") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0ea6560abb3bac1ffcfa4bf6b2c4d344fdc27b3c Mon Sep 17 00:00:00 2001 From: Zhang Yi <yi.zhang(a)huawei.com> Date: Fri, 17 May 2024 20:39:57 +0800 Subject: [PATCH] ext4: check the extent status again before inserting delalloc block ext4_da_map_blocks looks up for any extent entry in the extent status tree (w/o i_data_sem) and then the looks up for any ondisk extent mapping (with i_data_sem in read mode). If it finds a hole in the extent status tree or if it couldn't find any entry at all, it then takes the i_data_sem in write mode to add a da entry into the extent status tree. This can actually race with page mkwrite & fallocate path. Note that this is ok between 1. ext4 buffered-write path v/s ext4_page_mkwrite(), because of the folio lock 2. ext4 buffered write path v/s ext4 fallocate because of the inode lock. But this can race between ext4_page_mkwrite() & ext4 fallocate path ext4_page_mkwrite() ext4_fallocate() block_page_mkwrite() ext4_da_map_blocks() //find hole in extent status tree ext4_alloc_file_blocks() ext4_map_blocks() //allocate block and unwritten extent ext4_insert_delayed_block() ext4_da_reserve_space() //reserve one more block ext4_es_insert_delayed_block() //drop unwritten extent and add delayed extent by mistake Then, the delalloc extent is wrong until writeback and the extra reserved block can't be released any more and it triggers below warning: EXT4-fs (pmem2): Inode 13 (00000000bbbd4d23): i_reserved_data_blocks(1) not cleared! Fix the problem by looking up extent status tree again while the i_data_sem is held in write mode. If it still can't find any entry, then we insert a new da entry into the extent status tree. Cc: stable(a)vger.kernel.org Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Link: https://patch.msgid.link/20240517124005.347221-3-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 168819b4db01..4b0d64a76e88 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1737,6 +1737,7 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock, if (ext4_es_is_hole(&es)) goto add_delayed; +found: /* * Delayed extent could be allocated by fallocate. * So we need to check it. @@ -1781,6 +1782,26 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock, add_delayed: down_write(&EXT4_I(inode)->i_data_sem); + /* + * Page fault path (ext4_page_mkwrite does not take i_rwsem) + * and fallocate path (no folio lock) can race. Make sure we + * lookup the extent status tree here again while i_data_sem + * is held in write mode, before inserting a new da entry in + * the extent status tree. + */ + if (ext4_es_lookup_extent(inode, iblock, NULL, &es)) { + if (!ext4_es_is_hole(&es)) { + up_write(&EXT4_I(inode)->i_data_sem); + goto found; + } + } else if (!ext4_has_inline_data(inode)) { + retval = ext4_map_query_blocks(NULL, inode, map); + if (retval) { + up_write(&EXT4_I(inode)->i_data_sem); + return retval; + } + } + retval = ext4_insert_delayed_block(inode, map->m_lblk); up_write(&EXT4_I(inode)->i_data_sem); if (retval)

3 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] ext4: check the extent status again before inserting delalloc" 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 0ea6560abb3bac1ffcfa4bf6b2c4d344fdc27b3c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024072906-unshaven-whenever-406d@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 0ea6560abb3b ("ext4: check the extent status again before inserting delalloc block") acf795dc161f ("ext4: convert to exclusive lock while inserting delalloc extents") 3fcc2b887a1b ("ext4: refactor ext4_da_map_blocks()") 6c120399cde6 ("ext4: make ext4_es_insert_extent() return void") 2a69c450083d ("ext4: using nofail preallocation in ext4_es_insert_extent()") bda3efaf774f ("ext4: use pre-allocated es in __es_remove_extent()") 95f0b320339a ("ext4: use pre-allocated es in __es_insert_extent()") 73a2f033656b ("ext4: factor out __es_alloc_extent() and __es_free_extent()") 9649eb18c628 ("ext4: add a new helper to check if es must be kept") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 0ea6560abb3bac1ffcfa4bf6b2c4d344fdc27b3c Mon Sep 17 00:00:00 2001 From: Zhang Yi <yi.zhang(a)huawei.com> Date: Fri, 17 May 2024 20:39:57 +0800 Subject: [PATCH] ext4: check the extent status again before inserting delalloc block ext4_da_map_blocks looks up for any extent entry in the extent status tree (w/o i_data_sem) and then the looks up for any ondisk extent mapping (with i_data_sem in read mode). If it finds a hole in the extent status tree or if it couldn't find any entry at all, it then takes the i_data_sem in write mode to add a da entry into the extent status tree. This can actually race with page mkwrite & fallocate path. Note that this is ok between 1. ext4 buffered-write path v/s ext4_page_mkwrite(), because of the folio lock 2. ext4 buffered write path v/s ext4 fallocate because of the inode lock. But this can race between ext4_page_mkwrite() & ext4 fallocate path ext4_page_mkwrite() ext4_fallocate() block_page_mkwrite() ext4_da_map_blocks() //find hole in extent status tree ext4_alloc_file_blocks() ext4_map_blocks() //allocate block and unwritten extent ext4_insert_delayed_block() ext4_da_reserve_space() //reserve one more block ext4_es_insert_delayed_block() //drop unwritten extent and add delayed extent by mistake Then, the delalloc extent is wrong until writeback and the extra reserved block can't be released any more and it triggers below warning: EXT4-fs (pmem2): Inode 13 (00000000bbbd4d23): i_reserved_data_blocks(1) not cleared! Fix the problem by looking up extent status tree again while the i_data_sem is held in write mode. If it still can't find any entry, then we insert a new da entry into the extent status tree. Cc: stable(a)vger.kernel.org Signed-off-by: Zhang Yi <yi.zhang(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Link: https://patch.msgid.link/20240517124005.347221-3-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 168819b4db01..4b0d64a76e88 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1737,6 +1737,7 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock, if (ext4_es_is_hole(&es)) goto add_delayed; +found: /* * Delayed extent could be allocated by fallocate. * So we need to check it. @@ -1781,6 +1782,26 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock, add_delayed: down_write(&EXT4_I(inode)->i_data_sem); + /* + * Page fault path (ext4_page_mkwrite does not take i_rwsem) + * and fallocate path (no folio lock) can race. Make sure we + * lookup the extent status tree here again while i_data_sem + * is held in write mode, before inserting a new da entry in + * the extent status tree. + */ + if (ext4_es_lookup_extent(inode, iblock, NULL, &es)) { + if (!ext4_es_is_hole(&es)) { + up_write(&EXT4_I(inode)->i_data_sem); + goto found; + } + } else if (!ext4_has_inline_data(inode)) { + retval = ext4_map_query_blocks(NULL, inode, map); + if (retval) { + up_write(&EXT4_I(inode)->i_data_sem); + return retval; + } + } + retval = ext4_insert_delayed_block(inode, map->m_lblk); up_write(&EXT4_I(inode)->i_data_sem); if (retval)

3 months, 1 week

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2024