July 2024 - Linux-stable-mirror

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)

11 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)

11 months, 1 week

1
0
0 0

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

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-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.6.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 '2024072904-rule-emblem-471a@gregkh' --subject-prefix 'PATCH 6.6.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()") 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)

11 months, 1 week

1
0
0 0

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

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.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-6.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 '2024072903-oblong-old-80b6@gregkh' --subject-prefix 'PATCH 6.10.y' HEAD^.. Possible dependencies: 0ea6560abb3b ("ext4: check the extent status again before inserting delalloc block") 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)

11 months, 1 week

1
0
0 0

[tip: perf/core] perf/x86/intel/pt: Fix sampling synchronization

by tip-bot2 for Adrian Hunter

The following commit has been merged into the perf/core branch of tip: Commit-ID: d92792a4b26e50b96ab734cbe203d8a4c932a7a9 Gitweb: https://git.kernel.org/tip/d92792a4b26e50b96ab734cbe203d8a4c932a7a9 Author: Adrian Hunter <adrian.hunter(a)intel.com> AuthorDate: Mon, 15 Jul 2024 19:07:00 +03:00 Committer: Peter Zijlstra <peterz(a)infradead.org> CommitterDate: Mon, 29 Jul 2024 12:16:24 +02:00 perf/x86/intel/pt: Fix sampling synchronization pt_event_snapshot_aux() uses pt->handle_nmi to determine if tracing needs to be stopped, however tracing can still be going because pt->handle_nmi is set to zero before tracing is stopped in pt_event_stop, whereas pt_event_snapshot_aux() requires that tracing must be stopped in order to copy a sample of trace from the buffer. Instead call pt_config_stop() always, which anyway checks config for RTIT_CTL_TRACEEN and does nothing if it is already clear. Note pt_event_snapshot_aux() can continue to use pt->handle_nmi to determine if the trace needs to be restarted afterwards. Fixes: 25e8920b301c ("perf/x86/intel/pt: Add sampling support") Signed-off-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: stable(a)vger.kernel.org Link: https://lkml.kernel.org/r/20240715160712.127117-2-adrian.hunter@intel.com --- arch/x86/events/intel/pt.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c index b4aa8da..2959970 100644 --- a/arch/x86/events/intel/pt.c +++ b/arch/x86/events/intel/pt.c @@ -1606,6 +1606,7 @@ static void pt_event_stop(struct perf_event *event, int mode) * see comment in intel_pt_interrupt(). */ WRITE_ONCE(pt->handle_nmi, 0); + barrier(); pt_config_stop(event); @@ -1657,11 +1658,10 @@ static long pt_event_snapshot_aux(struct perf_event *event, return 0; /* - * Here, handle_nmi tells us if the tracing is on + * There is no PT interrupt in this mode, so stop the trace and it will + * remain stopped while the buffer is copied. */ - if (READ_ONCE(pt->handle_nmi)) - pt_config_stop(event); - + pt_config_stop(event); pt_read_offset(buf); pt_update_head(pt); @@ -1673,11 +1673,10 @@ static long pt_event_snapshot_aux(struct perf_event *event, ret = perf_output_copy_aux(&pt->handle, handle, from, to); /* - * If the tracing was on when we turned up, restart it. - * Compiler barrier not needed as we couldn't have been - * preempted by anything that touches pt->handle_nmi. + * Here, handle_nmi tells us if the tracing was on. + * If the tracing was on, restart it. */ - if (pt->handle_nmi) + if (READ_ONCE(pt->handle_nmi)) pt_config_start(event); return ret;

11 months, 1 week

1
0
0 0

Re: [PATCH 1/1] arm: devtree: fix missing device_node cleanup

by vincenzo mezzela

On 7/12/24 11:47, Javier Carrasco wrote: > On 12/07/2024 11:44, Vincenzo Mezzela wrote: >> Device node `cpus` is allocated but never released using `of_node_put`. >> >> This patch introduces the __free attribute for `cpus` device_node that >> automatically handle the cleanup of the resource by adding a call to >> `of_node_put` at the end of the current scope. This enhancement aims to >> mitigate memory management issues associated with forgetting to release >> the resources. >> >> Signed-off-by: Vincenzo Mezzela <vincenzo.mezzela(a)gmail.com> >> --- >> arch/arm/kernel/devtree.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c >> index fdb74e64206a..223d66a5fff3 100644 >> --- a/arch/arm/kernel/devtree.c >> +++ b/arch/arm/kernel/devtree.c >> @@ -70,14 +70,14 @@ void __init arm_dt_init_cpu_maps(void) >> * contain a list of MPIDR[23:0] values where MPIDR[31:24] must >> * read as 0. >> */ >> - struct device_node *cpu, *cpus; >> int found_method = 0; >> u32 i, j, cpuidx = 1; >> u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0; >> >> u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID }; >> bool bootcpu_valid = false; >> - cpus = of_find_node_by_path("/cpus"); >> + struct device_node *cpu; >> + struct device_node *cpus __free(device_node) = of_find_node_by_path("/cpus"); >> >> if (!cpus) >> return; > Hello Vincenzo, > > If this is a fix, please provide the Fixes: tag as well as Cc: for > stable if it applies. > > Best regards, Javier Carrasco Sure, will do. :) Best regards, Vincenzo Fixes: a0ae02405076a ("ARM: kernel: add device tree init map function") Cc: stable(a)vger.kernel.org

11 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] udf: Avoid using corrupted block bitmap buffer" 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 a90d4471146de21745980cba51ce88e7926bcc4f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024072927-stubbly-curler-09c4@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: a90d4471146d ("udf: Avoid using corrupted block bitmap buffer") 1e0d4adf17e7 ("udf: Check consistency of Space Bitmap Descriptor") 101ee137d32a ("udf: Drop VARCONV support") a27b2923de7e ("udf: Move udf_expand_dir_adinicb() to its callsite") 57bda9fb169d ("udf: Convert udf_expand_dir_adinicb() to new directory iteration") d16076d9b684 ("udf: New directory iteration code") e4ae4735f7c2 ("udf: use sb_bdev_nr_blocks") b64533344371 ("udf: Fix iocharset=utf8 mount option") 979a6e28dd96 ("udf: Get rid of 0-length arrays in struct fileIdentDesc") fa236c2b2d44 ("udf: Fix NULL pointer dereference in udf_symlink function") 382a2287bf9c ("udf: Remove pointless union in udf_inode_info") 044e2e26f214 ("udf: Avoid accessing uninitialized data on failed inode read") 8b075e5ba459 ("udf: stop using ioctl_by_bdev") 4eb09e111218 ("fs-udf: Delete an unnecessary check before brelse()") ab9a3a737284 ("udf: reduce leakage of blocks related to named streams") a768a9abc625 ("udf: Explain handling of load_nls() failure") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a90d4471146de21745980cba51ce88e7926bcc4f Mon Sep 17 00:00:00 2001 From: Jan Kara <jack(a)suse.cz> Date: Mon, 17 Jun 2024 17:41:52 +0200 Subject: [PATCH] udf: Avoid using corrupted block bitmap buffer When the filesystem block bitmap is corrupted, we detect the corruption while loading the bitmap and fail the allocation with error. However the next allocation from the same bitmap will notice the bitmap buffer is already loaded and tries to allocate from the bitmap with mixed results (depending on the exact nature of the bitmap corruption). Fix the problem by using BH_verified bit to indicate whether the bitmap is valid or not. Reported-by: syzbot+5f682cd029581f9edfd1(a)syzkaller.appspotmail.com CC: stable(a)vger.kernel.org Link: https://patch.msgid.link/20240617154201.29512-2-jack@suse.cz Fixes: 1e0d4adf17e7 ("udf: Check consistency of Space Bitmap Descriptor") Signed-off-by: Jan Kara <jack(a)suse.cz> diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c index ab3ffc355949..558ad046972a 100644 --- a/fs/udf/balloc.c +++ b/fs/udf/balloc.c @@ -64,8 +64,12 @@ static int read_block_bitmap(struct super_block *sb, } for (i = 0; i < count; i++) - if (udf_test_bit(i + off, bh->b_data)) + if (udf_test_bit(i + off, bh->b_data)) { + bitmap->s_block_bitmap[bitmap_nr] = + ERR_PTR(-EFSCORRUPTED); + brelse(bh); return -EFSCORRUPTED; + } return 0; } @@ -81,8 +85,15 @@ static int __load_block_bitmap(struct super_block *sb, block_group, nr_groups); } - if (bitmap->s_block_bitmap[block_group]) + if (bitmap->s_block_bitmap[block_group]) { + /* + * The bitmap failed verification in the past. No point in + * trying again. + */ + if (IS_ERR(bitmap->s_block_bitmap[block_group])) + return PTR_ERR(bitmap->s_block_bitmap[block_group]); return block_group; + } retval = read_block_bitmap(sb, bitmap, block_group, block_group); if (retval < 0) diff --git a/fs/udf/super.c b/fs/udf/super.c index 9381a66c6ce5..92d477053905 100644 --- a/fs/udf/super.c +++ b/fs/udf/super.c @@ -336,7 +336,8 @@ static void udf_sb_free_bitmap(struct udf_bitmap *bitmap) int nr_groups = bitmap->s_nr_groups; for (i = 0; i < nr_groups; i++) - brelse(bitmap->s_block_bitmap[i]); + if (!IS_ERR_OR_NULL(bitmap->s_block_bitmap[i])) + brelse(bitmap->s_block_bitmap[i]); kvfree(bitmap); }

11 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] apparmor: use kvfree_sensitive to free data->data" 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 2bc73505a5cd2a18a7a542022722f136c19e3b87 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024072905-twirl-endless-6a91@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 2bc73505a5cd ("apparmor: use kvfree_sensitive to free data->data") 000518bc5aef ("apparmor: fix missing error check for rhashtable_insert_fast") 453431a54934 ("mm, treewide: rename kzfree() to kfree_sensitive()") 45365a06aa30 ("Merge tag 's390-5.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2bc73505a5cd2a18a7a542022722f136c19e3b87 Mon Sep 17 00:00:00 2001 From: Fedor Pchelkin <pchelkin(a)ispras.ru> Date: Thu, 1 Feb 2024 17:24:48 +0300 Subject: [PATCH] apparmor: use kvfree_sensitive to free data->data Inside unpack_profile() data->data is allocated using kvmemdup() so it should be freed with the corresponding kvfree_sensitive(). Also add missing data->data release for rhashtable insertion failure path in unpack_profile(). Found by Linux Verification Center (linuxtesting.org). Fixes: e025be0f26d5 ("apparmor: support querying extended trusted helper extra data") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Signed-off-by: John Johansen <john.johansen(a)canonical.com> diff --git a/security/apparmor/policy.c b/security/apparmor/policy.c index 957654d253dd..14df15e35695 100644 --- a/security/apparmor/policy.c +++ b/security/apparmor/policy.c @@ -225,7 +225,7 @@ static void aa_free_data(void *ptr, void *arg) { struct aa_data *data = ptr; - kfree_sensitive(data->data); + kvfree_sensitive(data->data, data->size); kfree_sensitive(data->key); kfree_sensitive(data); } diff --git a/security/apparmor/policy_unpack.c b/security/apparmor/policy_unpack.c index 5e578ef0ddff..75452acd0e35 100644 --- a/security/apparmor/policy_unpack.c +++ b/security/apparmor/policy_unpack.c @@ -1071,6 +1071,7 @@ static struct aa_profile *unpack_profile(struct aa_ext *e, char **ns_name) if (rhashtable_insert_fast(profile->data, &data->head, profile->data->p)) { + kvfree_sensitive(data->data, data->size); kfree_sensitive(data->key); kfree_sensitive(data); info = "failed to insert data to table";

11 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] apparmor: use kvfree_sensitive to free data->data" 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 2bc73505a5cd2a18a7a542022722f136c19e3b87 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024072904-landmass-fragrant-ef08@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 2bc73505a5cd ("apparmor: use kvfree_sensitive to free data->data") 000518bc5aef ("apparmor: fix missing error check for rhashtable_insert_fast") 453431a54934 ("mm, treewide: rename kzfree() to kfree_sensitive()") 45365a06aa30 ("Merge tag 's390-5.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2bc73505a5cd2a18a7a542022722f136c19e3b87 Mon Sep 17 00:00:00 2001 From: Fedor Pchelkin <pchelkin(a)ispras.ru> Date: Thu, 1 Feb 2024 17:24:48 +0300 Subject: [PATCH] apparmor: use kvfree_sensitive to free data->data Inside unpack_profile() data->data is allocated using kvmemdup() so it should be freed with the corresponding kvfree_sensitive(). Also add missing data->data release for rhashtable insertion failure path in unpack_profile(). Found by Linux Verification Center (linuxtesting.org). Fixes: e025be0f26d5 ("apparmor: support querying extended trusted helper extra data") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Signed-off-by: John Johansen <john.johansen(a)canonical.com> diff --git a/security/apparmor/policy.c b/security/apparmor/policy.c index 957654d253dd..14df15e35695 100644 --- a/security/apparmor/policy.c +++ b/security/apparmor/policy.c @@ -225,7 +225,7 @@ static void aa_free_data(void *ptr, void *arg) { struct aa_data *data = ptr; - kfree_sensitive(data->data); + kvfree_sensitive(data->data, data->size); kfree_sensitive(data->key); kfree_sensitive(data); } diff --git a/security/apparmor/policy_unpack.c b/security/apparmor/policy_unpack.c index 5e578ef0ddff..75452acd0e35 100644 --- a/security/apparmor/policy_unpack.c +++ b/security/apparmor/policy_unpack.c @@ -1071,6 +1071,7 @@ static struct aa_profile *unpack_profile(struct aa_ext *e, char **ns_name) if (rhashtable_insert_fast(profile->data, &data->head, profile->data->p)) { + kvfree_sensitive(data->data, data->size); kfree_sensitive(data->key); kfree_sensitive(data); info = "failed to insert data to table";

11 months, 1 week

1
0
0 0

Re: [PATCH v3] sched/fair: Use all little CPUs for CPU-bound workload

by Pierre Gondois

Hello stable folk, This patch was merged as: commit 3af7524b1419 ("sched/fair: Use all little CPUs for CPU-bound workloads") into 6.7, improving the following: commit 0b0695f2b34a ("sched/fair: Rework load_balance()") Would it be possible to port it to the 6.1 stable branch ? The patch should apply cleanly by cherry-picking onto v6.1.94, Regards, Pierre On 12/6/23 10:00, Pierre Gondois wrote: > Running n CPU-bound tasks on an n CPUs platform: > - with asymmetric CPU capacity > - not being a DynamIq system (i.e. having a PKG level sched domain > without the SD_SHARE_PKG_RESOURCES flag set) > might result in a task placement where two tasks run on a big CPU > and none on a little CPU. This placement could be more optimal by > using all CPUs. > > Testing platform: > Juno-r2: > - 2 big CPUs (1-2), maximum capacity of 1024 > - 4 little CPUs (0,3-5), maximum capacity of 383 > > Testing workload ([1]): > Spawn 6 CPU-bound tasks. During the first 100ms (step 1), each tasks > is affine to a CPU, except for: > - one little CPU which is left idle. > - one big CPU which has 2 tasks affine. > After the 100ms (step 2), remove the cpumask affinity. > > Before patch: > During step 2, the load balancer running from the idle CPU tags sched > domains as: > - little CPUs: 'group_has_spare'. Cf. group_has_capacity() and > group_is_overloaded(), 3 CPU-bound tasks run on a 4 CPUs > sched-domain, and the idle CPU provides enough spare capacity > regarding the imbalance_pct > - big CPUs: 'group_overloaded'. Indeed, 3 tasks run on a 2 CPUs > sched-domain, so the following path is used: > group_is_overloaded() > \-if (sgs->sum_nr_running <= sgs->group_weight) return true; > > The following path which would change the migration type to > 'migrate_task' is not taken: > calculate_imbalance() > \-if (env->idle != CPU_NOT_IDLE && env->imbalance == 0) > as the local group has some spare capacity, so the imbalance > is not 0. > > The migration type requested is 'migrate_util' and the busiest > runqueue is the big CPU's runqueue having 2 tasks (each having a > utilization of 512). The idle little CPU cannot pull one of these > task as its capacity is too small for the task. The following path > is used: > detach_tasks() > \-case migrate_util: > \-if (util > env->imbalance) goto next; > > After patch: > As the number of failed balancing attempts grows (with > 'nr_balance_failed'), progressively make it easier to migrate > a big task to the idling little CPU. A similar mechanism is > used for the 'migrate_load' migration type. > > Improvement: > Running the testing workload [1] with the step 2 representing > a ~10s load for a big CPU: > Before patch: ~19.3s > After patch: ~18s (-6.7%) > > Similar issue reported at: > https://lore.kernel.org/lkml/20230716014125.139577-1-qyousef@layalina.io/ > > v1: > https://lore.kernel.org/all/20231110125902.2152380-1-pierre.gondois@arm.com/ > v2: > https://lore.kernel.org/all/20231124153323.3202444-1-pierre.gondois@arm.com/ > > Suggested-by: Vincent Guittot <vincent.guittot(a)linaro.org> > Signed-off-by: Pierre Gondois <pierre.gondois(a)arm.com> > Reviewed-by: Vincent Guittot <vincent.guittot(a)linaro.org> > Reviewed-by: Dietmar Eggemann <dietmar.eggemann(a)arm.com> > --- > > Notes: > v2: > - Used Vincent's approach. > v3: > - Updated commit message. > - Added Reviewed-by tags > > kernel/sched/fair.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index d7a3c63a2171..9481b8cff31b 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -9060,7 +9060,7 @@ static int detach_tasks(struct lb_env *env) > case migrate_util: > util = task_util_est(p); > > - if (util > env->imbalance) > + if (shr_bound(util, env->sd->nr_balance_failed) > env->imbalance) > goto next; > > env->imbalance -= util;

11 months, 1 week

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2024