From: Masahiro Yamada masahiroy@kernel.org
[ Upstream commit cae9cdbcd9af044810bcceeb43a87accca47c71d ]
The on_treeview2_cursor_changed() handler is connected to both the left and right tree views, but it hardcodes model2 (the GtkTreeModel of the right tree view). This is incorrect. Get the associated model from the view.
Signed-off-by: Masahiro Yamada masahiroy@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Let me check the commit you provided more carefully. Looking at the diff:
The commit changes line 851-852 in the `on_treeview2_cursor_changed` function from: ```c if (gtk_tree_selection_get_selected(selection, &model2, &iter)) { gtk_tree_model_get(model2, &iter, COL_MENU, &menu, -1); ```
To: ```c if (gtk_tree_selection_get_selected(selection, &model, &iter)) { gtk_tree_model_get(model, &iter, COL_MENU, &menu, -1); ```
Where `model` is obtained from: `GtkTreeModel *model = gtk_tree_view_get_model(treeview);`
This is indeed a bug fix. The function `on_treeview2_cursor_changed()` is connected as a signal handler to BOTH tree views (tree1_w and tree2_w), as shown in the connection code around lines 989 and 997. However, the old code hardcoded `model2` which is specifically the model for the right tree view. This would cause incorrect behavior when the handler is triggered from the left tree view (tree1_w).
**Backport Status: YES**
## Extensive Analysis:
### Bug Description: The commit fixes a clear bug in the gconf GUI tool for kernel configuration. The `on_treeview2_cursor_changed()` function is used as a signal handler for cursor changes in both the left and right tree views of the configuration interface. However, the function incorrectly hardcoded `model2` (the GtkTreeModel for the right tree view) instead of dynamically getting the model from whichever view triggered the event.
### Code Analysis: 1. **Signal Connection** (lines 988-997 in the repository): - The same handler is connected to both tree views: ```c g_signal_connect(tree1_w, "cursor-changed", G_CALLBACK(on_treeview2_cursor_changed), NULL); g_signal_connect(tree2_w, "cursor-changed", G_CALLBACK(on_treeview2_cursor_changed), NULL); ```
2. **The Bug**: When the cursor changes in tree1_w (left tree), the handler would incorrectly use model2 (right tree's model) to get the selected item, potentially causing: - Incorrect help text display - Crashes if the models have different structures - Undefined behavior when accessing invalid iterators
3. **The Fix**: The commit correctly obtains the model from the treeview parameter that triggered the event: ```c GtkTreeModel *model = gtk_tree_view_get_model(treeview); ``` This ensures the correct model is used regardless of which tree view triggered the event.
### Backport Justification: 1. **Clear Bug Fix**: This fixes an obvious programming error that affects functionality 2. **Small and Contained**: The change is minimal (2 lines modified) and localized to a single function 3. **Low Risk**: The fix is straightforward and correct - getting the model from the actual tree view instead of hardcoding 4. **User Impact**: This bug could affect users of the gconf configuration tool, potentially causing crashes or incorrect behavior 5. **No Architectural Changes**: This is a simple bug fix with no design changes 6. **No New Features**: Pure bug fix, no functionality additions
This is an ideal candidate for stable backporting as it's a clear, minimal bug fix that improves reliability without introducing risk.
scripts/kconfig/gconf.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/scripts/kconfig/gconf.c b/scripts/kconfig/gconf.c index c0f46f189060..abe4cfe66b14 100644 --- a/scripts/kconfig/gconf.c +++ b/scripts/kconfig/gconf.c @@ -942,13 +942,14 @@ on_treeview2_key_press_event(GtkWidget * widget, void on_treeview2_cursor_changed(GtkTreeView * treeview, gpointer user_data) { + GtkTreeModel *model = gtk_tree_view_get_model(treeview); GtkTreeSelection *selection; GtkTreeIter iter; struct menu *menu;
selection = gtk_tree_view_get_selection(treeview); - if (gtk_tree_selection_get_selected(selection, &model2, &iter)) { - gtk_tree_model_get(model2, &iter, COL_MENU, &menu, -1); + if (gtk_tree_selection_get_selected(selection, &model, &iter)) { + gtk_tree_model_get(model, &iter, COL_MENU, &menu, -1); text_insert_help(menu); } }
From: Masahiro Yamada masahiroy@kernel.org
[ Upstream commit 626c54af35764b0b8a4ed5c446458ba6ddfe9cc8 ]
When a header file is changed, kernel/gen_kheaders.sh may fail to update kernel/kheaders_data.tar.xz.
[steps to reproduce]
[1] Build kernel/kheaders_data.tar.xz
$ make -j$(nproc) kernel/kheaders.o DESCEND objtool INSTALL libsubcmd_headers CALL scripts/checksyscalls.sh CHK kernel/kheaders_data.tar.xz GEN kernel/kheaders_data.tar.xz CC kernel/kheaders.o
[2] Modify a header without changing the file size
$ sed -i s/0xdeadbeef/0xfeedbeef/ include/linux/elfnote.h
[3] Rebuild kernel/kheaders_data.tar.xz
$ make -j$(nproc) kernel/kheaders.o DESCEND objtool INSTALL libsubcmd_headers CALL scripts/checksyscalls.sh CHK kernel/kheaders_data.tar.xz
kernel/kheaders_data.tar.xz is not updated if steps [1] - [3] are run within the same minute.
The headers_md5 variable stores the MD5 hash of the 'ls -l' output for all header files. This hash value is used to determine whether kheaders_data.tar.xz needs to be rebuilt. However, 'ls -l' prints the modification times with minute-level granularity. If a file is modified within the same minute and its size remains the same, the MD5 hash does not change.
To reliably detect file modifications, this commit rewrites kernel/gen_kheaders.sh to output header dependencies to kernel/.kheaders_data.tar.xz.cmd. Then, Make compares the timestamps and reruns kernel/gen_kheaders.sh when necessary. This is the standard mechanism used by Make and Kbuild.
Signed-off-by: Masahiro Yamada masahiroy@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
**Backport Status: YES**
This commit should be backported to stable kernel trees for the following reasons:
## Bug Fix Nature The commit fixes a genuine bug where header file modifications fail to trigger a rebuild of `kheaders_data.tar.xz` when changes occur within the same minute. This is a **reliability issue** that affects the correctness of the kernel build system, particularly for CONFIG_IKHEADERS functionality.
## Specific Problem Being Fixed The previous implementation had a **race condition** where: - The MD5 hash was calculated from `ls -l` output which shows modification times with minute-level granularity - If a file was modified within the same minute without changing its size, the MD5 hash wouldn't change - This caused the build system to miss legitimate file changes, resulting in stale header archives
## Impact on Users This bug directly affects: 1. Kernel developers doing incremental builds 2. Tools and scripts that rely on CONFIG_IKHEADERS having accurate header information 3. Automated build systems that may make rapid successive changes
## Size and Complexity Analysis The changes are: - **Contained to a single subsystem** (kheaders build infrastructure) - **Relatively small** (3 files, +66/-77 lines net change) - **Uses standard Kbuild mechanisms** - the fix replaces the custom MD5-based change detection with Make's standard dependency tracking via `.cmd` files - **No architectural changes** - just improves the existing build dependency tracking
## Risk Assessment The fix has **minimal regression risk** because: 1. It replaces a brittle custom mechanism with the well-tested standard Kbuild dependency tracking 2. The changes are isolated to the kheaders build process 3. It doesn't affect runtime behavior, only build-time behavior 4. The new implementation is actually simpler and more maintainable than the old one
## Code Quality Improvements The commit also brings these benefits: - Removes 77 lines of complex shell script logic - Uses standard Make dependency files (`.kheaders_data.tar.xz.cmd`) - Properly tracks both source files (`kheaders-srclist`) and object files (`kheaders-objlist`) - More reliable change detection using file timestamps rather than MD5 of `ls -l` output
## Stable Tree Criteria This commit meets stable tree requirements: - ✅ Fixes a real bug that affects users (incremental builds failing to detect changes) - ✅ Small and contained changes - ✅ No new features introduced - ✅ Uses existing, proven mechanisms (standard Make dependency tracking) - ✅ Low risk of regression - ✅ Clear reproduction steps provided in commit message
The commit is particularly important for stable because build system reliability is crucial for kernel development workflows, and this bug could lead to subtle issues where developers think they're testing updated headers when they're actually using stale ones.
kernel/.gitignore | 2 + kernel/Makefile | 47 ++++++++++++++++++--- kernel/gen_kheaders.sh | 94 ++++++++++-------------------------------- 3 files changed, 66 insertions(+), 77 deletions(-)
diff --git a/kernel/.gitignore b/kernel/.gitignore index c6b299a6b786..a501bfc80694 100644 --- a/kernel/.gitignore +++ b/kernel/.gitignore @@ -1,3 +1,5 @@ # SPDX-License-Identifier: GPL-2.0-only /config_data /kheaders.md5 +/kheaders-objlist +/kheaders-srclist diff --git a/kernel/Makefile b/kernel/Makefile index 32e80dd626af..9a9ff405ea89 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -158,11 +158,48 @@ filechk_cat = cat $< $(obj)/config_data: $(KCONFIG_CONFIG) FORCE $(call filechk,cat)
+# kheaders_data.tar.xz $(obj)/kheaders.o: $(obj)/kheaders_data.tar.xz
-quiet_cmd_genikh = CHK $(obj)/kheaders_data.tar.xz - cmd_genikh = $(CONFIG_SHELL) $(srctree)/kernel/gen_kheaders.sh $@ -$(obj)/kheaders_data.tar.xz: FORCE - $(call cmd,genikh) +quiet_cmd_kheaders_data = GEN $@ + cmd_kheaders_data = "$<" "$@" "$(obj)/kheaders-srclist" "$(obj)/kheaders-objlist" + cmd_kheaders_data_dep = cat $(depfile) >> $(dot-target).cmd; rm -f $(depfile)
-clean-files := kheaders_data.tar.xz kheaders.md5 +define rule_kheaders_data + $(call cmd_and_savecmd,kheaders_data) + $(call cmd,kheaders_data_dep) +endef + +targets += kheaders_data.tar.xz +$(obj)/kheaders_data.tar.xz: $(src)/gen_kheaders.sh $(obj)/kheaders-srclist $(obj)/kheaders-objlist $(obj)/kheaders.md5 FORCE + $(call if_changed_rule,kheaders_data) + +# generated headers in objtree +# +# include/generated/utsversion.h is ignored because it is generated +# after gen_kheaders.sh is executed. (utsversion.h is unneeded for kheaders) +filechk_kheaders_objlist = \ + for d in include "arch/$(SRCARCH)/include"; do \ + find "$${d}/generated" ! -path "include/generated/utsversion.h" -a -name "*.h" -print; \ + done + +$(obj)/kheaders-objlist: FORCE + $(call filechk,kheaders_objlist) + +# non-generated headers in srctree +filechk_kheaders_srclist = \ + for d in include "arch/$(SRCARCH)/include"; do \ + find "$(srctree)/$${d}" -path "$(srctree)/$${d}/generated" -prune -o -name "*.h" -print; \ + done + +$(obj)/kheaders-srclist: FORCE + $(call filechk,kheaders_srclist) + +# Some files are symlinks. If symlinks are changed, kheaders_data.tar.xz should +# be rebuilt. +filechk_kheaders_md5sum = xargs -r -a $< stat -c %N | md5sum + +$(obj)/kheaders.md5: $(obj)/kheaders-srclist FORCE + $(call filechk,kheaders_md5sum) + +clean-files := kheaders.md5 kheaders-srclist kheaders-objlist diff --git a/kernel/gen_kheaders.sh b/kernel/gen_kheaders.sh index c9e5dc068e85..0ff7beabb21a 100755 --- a/kernel/gen_kheaders.sh +++ b/kernel/gen_kheaders.sh @@ -4,79 +4,33 @@ # This script generates an archive consisting of kernel headers # for CONFIG_IKHEADERS. set -e -sfile="$(readlink -f "$0")" -outdir="$(pwd)" tarfile=$1 -tmpdir=$outdir/${tarfile%/*}/.tmp_dir - -dir_list=" -include/ -arch/$SRCARCH/include/ -" - -# Support incremental builds by skipping archive generation -# if timestamps of files being archived are not changed. - -# This block is useful for debugging the incremental builds. -# Uncomment it for debugging. -# if [ ! -f /tmp/iter ]; then iter=1; echo 1 > /tmp/iter; -# else iter=$(($(cat /tmp/iter) + 1)); echo $iter > /tmp/iter; fi -# find $all_dirs -name "*.h" | xargs ls -l > /tmp/ls-$iter - -all_dirs= -if [ "$building_out_of_srctree" ]; then - for d in $dir_list; do - all_dirs="$all_dirs $srctree/$d" - done -fi -all_dirs="$all_dirs $dir_list" - -# include/generated/utsversion.h is ignored because it is generated after this -# script is executed. (utsversion.h is unneeded for kheaders) -# -# When Kconfig regenerates include/generated/autoconf.h, its timestamp is -# updated, but the contents might be still the same. When any CONFIG option is -# changed, Kconfig touches the corresponding timestamp file include/config/*. -# Hence, the md5sum detects the configuration change anyway. We do not need to -# check include/generated/autoconf.h explicitly. -# -# Ignore them for md5 calculation to avoid pointless regeneration. -headers_md5="$(find $all_dirs -name "*.h" -a \ - ! -path include/generated/utsversion.h -a \ - ! -path include/generated/autoconf.h | - xargs ls -l | md5sum | cut -d ' ' -f1)" - -# Any changes to this script will also cause a rebuild of the archive. -this_file_md5="$(ls -l $sfile | md5sum | cut -d ' ' -f1)" -if [ -f $tarfile ]; then tarfile_md5="$(md5sum $tarfile | cut -d ' ' -f1)"; fi -if [ -f kernel/kheaders.md5 ] && - [ "$(head -n 1 kernel/kheaders.md5)" = "$headers_md5" ] && - [ "$(head -n 2 kernel/kheaders.md5 | tail -n 1)" = "$this_file_md5" ] && - [ "$(tail -n 1 kernel/kheaders.md5)" = "$tarfile_md5" ]; then - exit -fi - -echo " GEN $tarfile" +srclist=$2 +objlist=$3 + +dir=$(dirname "${tarfile}") +tmpdir=${dir}/.tmp_dir +depfile=${dir}/.$(basename "${tarfile}").d + +# generate dependency list. +{ + echo + echo "deps_${tarfile} := \" + sed 's:(.*): \1 \:' "${srclist}" + sed -n '/^include/generated/autoconf.h$/!s:(.*): \1 \:p' "${objlist}" + echo + echo "${tarfile}: $(deps_${tarfile})" + echo + echo "$(deps_${tarfile}):" + +} > "${depfile}"
rm -rf "${tmpdir}" mkdir "${tmpdir}"
-if [ "$building_out_of_srctree" ]; then - ( - cd $srctree - for f in $dir_list - do find "$f" -name "*.h"; - done | tar -c -f - -T - | tar -xf - -C "${tmpdir}" - ) -fi - -for f in $dir_list; - do find "$f" -name "*.h"; -done | tar -c -f - -T - | tar -xf - -C "${tmpdir}" - -# Always exclude include/generated/utsversion.h -# Otherwise, the contents of the tarball may vary depending on the build steps. -rm -f "${tmpdir}/include/generated/utsversion.h" +# shellcheck disable=SC2154 # srctree is passed as an env variable +sed "s:^${srctree}/::" "${srclist}" | tar -c -f - -C "${srctree}" -T - | tar -xf - -C "${tmpdir}" +tar -c -f - -T "${objlist}" | tar -xf - -C "${tmpdir}"
# Remove comments except SDPX lines # Use a temporary file to store directory contents to prevent find/xargs from @@ -92,8 +46,4 @@ tar "${KBUILD_BUILD_TIMESTAMP:+--mtime=$KBUILD_BUILD_TIMESTAMP}" \ --owner=0 --group=0 --sort=name --numeric-owner --mode=u=rw,go=r,a+X \ -I $XZ -cf $tarfile -C "${tmpdir}/" . > /dev/null
-echo $headers_md5 > kernel/kheaders.md5 -echo "$this_file_md5" >> kernel/kheaders.md5 -echo "$(md5sum $tarfile | cut -d ' ' -f1)" >> kernel/kheaders.md5 - rm -rf "${tmpdir}"
From: "Yann E. MORIN" yann.morin.1998@free.fr
[ Upstream commit 694174f94ebeeb5ec5cc0e9de9b40c82057e1d95 ]
In case a menu has comment without letters/numbers (eg. characters matching the regexp '^[^[:alpha:][:digit:]]+$', for example - or *), hitting space will cycle through those comments, rather than selecting/deselecting the currently-highlighted option.
This is the behaviour of hitting any letter/digit: jump to the next option which prompt starts with that letter. The only letters that do not behave as such are 'y' 'm' and 'n'. Prompts that start with one of those three letters are instead matched on the first letter that is not 'y', 'm' or 'n'.
Fix that by treating 'space' as we treat y/m/n, ie. as an action key, not as shortcut to jump to prompt.
Signed-off-by: Yann E. MORIN yann.morin.1998@free.fr Signed-off-by: Peter Korsgaard peter@korsgaard.com Signed-off-by: Cherniaev Andrei dungeonlords789@naver.com [masahiro: took from Buildroot, adjusted the commit subject] Signed-off-by: Masahiro Yamada masahiroy@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Now I have a complete understanding of the bug and fix. Let me provide my analysis:
**Backport Status: YES**
## Extensive Analysis:
This commit fixes a **clear user interface bug** in the kernel's menuconfig system (lxdialog) that affects the fundamental usability of kernel configuration. Here's the detailed analysis:
### The Bug: When a menu contains comment lines that start with non-alphanumeric characters (like `-`, `*`, or other special characters matching `^[^[:alpha:][:digit:]]+$`), pressing the space bar incorrectly cycles through these comment items instead of selecting/deselecting the currently highlighted option.
### Root Cause (from code analysis):
1. **Line 267 (original)**: The condition `if (strchr("ynmh", key))` checks if the pressed key is one of the special action keys (`y`, `n`, `m`, `h`). If it is, it sets `i = max_choice` to skip the jump- to-prompt logic.
2. **Lines 269-282**: For any other key (including space), the code searches for menu items starting with that character, treating it as a shortcut to jump to prompts beginning with that letter.
3. **The problem**: Space (ASCII 32) was not included in the special action keys list, so when pressed, it would trigger the jump-to- prompt logic. If menu items had comments starting with spaces or special characters, the space key would match these and jump to them instead of performing its intended action.
4. **Lines 362-398**: The switch statement shows that space (line 362) IS supposed to be an action key that returns value 8 (line 397-398), which indicates a selection/deselection action.
### The Fix: The fix is minimal and surgical - changing line 267 from: ```c if (strchr("ynmh", key)) ``` to: ```c if (strchr("ynmh ", key)) // Added space character ```
This ensures space is treated as an action key, not as a jump-to-prompt shortcut.
### Why This Should Be Backported:
1. **Fixes a real user-facing bug**: This directly impacts anyone using menuconfig to configure the kernel, which is a fundamental tool for kernel configuration.
2. **Minimal and contained fix**: The change is a single character addition with no architectural changes or new features.
3. **Low regression risk**: The fix only affects the specific broken behavior and restores the intended functionality that's already defined in the switch statement.
4. **Long-standing issue**: The commit message indicates this came from Buildroot, suggesting it's been affecting users across multiple projects for some time.
5. **Clear behavioral inconsistency**: The code clearly shows space was meant to be an action key (returning value 8 in the switch statement), but was incorrectly handled in the shortcut logic.
6. **No side effects**: The change only affects space key handling in menuconfig and doesn't touch any kernel runtime code or critical subsystems.
This is an ideal stable backport candidate - it fixes a clear bug with minimal change and risk.
scripts/kconfig/lxdialog/menubox.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kconfig/lxdialog/menubox.c b/scripts/kconfig/lxdialog/menubox.c index 6e6244df0c56..d4c19b7beebb 100644 --- a/scripts/kconfig/lxdialog/menubox.c +++ b/scripts/kconfig/lxdialog/menubox.c @@ -264,7 +264,7 @@ int dialog_menu(const char *title, const char *prompt, if (key < 256 && isalpha(key)) key = tolower(key);
- if (strchr("ynmh", key)) + if (strchr("ynmh ", key)) i = max_choice; else { for (i = choice + 1; i < max_choice; i++) {
From: John Garry john.g.garry@oracle.com
[ Upstream commit dafeaf2c03e71255438ffe5a341d94d180e6c88e ]
When PCI_IRQ_AFFINITY is set for calling pci_alloc_irq_vectors(), it means interrupts are spread around the available CPUs. It also means that the interrupts become managed, which means that an interrupt is shutdown when all the CPUs in the interrupt affinity mask go offline.
Using managed interrupts in this way means that we should ensure that completions should not occur on HW queues where the associated interrupt is shutdown. This is typically achieved by ensuring only CPUs which are online can generate IO completion traffic to the HW queue which they are mapped to (so that they can also serve completion interrupts for that HW queue).
The problem in the driver is that a CPU can generate completions to a HW queue whose interrupt may be shutdown, as the CPUs in the HW queue interrupt affinity mask may be offline. This can cause IOs to never complete and hang the system. The driver maintains its own CPU <-> HW queue mapping for submissions, see aac_fib_vector_assign(), but this does not reflect the CPU <-> HW queue interrupt affinity mapping.
Commit 9dc704dcc09e ("scsi: aacraid: Reply queue mapping to CPUs based on IRQ affinity") tried to remedy this issue may mapping CPUs properly to HW queue interrupts. However this was later reverted in commit c5becf57dd56 ("Revert "scsi: aacraid: Reply queue mapping to CPUs based on IRQ affinity") - it seems that there were other reports of hangs. I guess that this was due to some implementation issue in the original commit or maybe a HW issue.
Fix the very original hang by just not using managed interrupts by not setting PCI_IRQ_AFFINITY. In this way, all CPUs will be in each HW queue affinity mask, so should not create completion problems if any CPUs go offline.
Signed-off-by: John Garry john.g.garry@oracle.com Link: https://lore.kernel.org/r/20250715111535.499853-1-john.g.garry@oracle.com Closes: https://lore.kernel.org/linux-scsi/20250618192427.3845724-1-jmeneghi@redhat.... Reviewed-by: John Meneghini jmeneghi@redhat.com Tested-by: John Meneghini jmeneghi@redhat.com Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Based on my analysis, here is my determination:
**Backport Status: YES**
This commit should be backported to stable kernel trees for the following reasons:
1. **Fixes a Critical Bug**: The commit fixes a system hang issue that occurs when CPUs go offline. The code change shows it removes `PCI_IRQ_AFFINITY` flag from `pci_alloc_irq_vectors()` call (line 485 changing from `PCI_IRQ_MSIX | PCI_IRQ_AFFINITY` to just `PCI_IRQ_MSIX`). This prevents managed interrupts from being shut down when CPUs go offline, which was causing I/O operations to never complete and hang the system.
2. **Long-Standing Issue with History**: The commit message reveals this is addressing a long-standing problem that has been attempted to be fixed before: - Commit 9dc704dcc09e tried to fix it by mapping CPUs properly to HW queue interrupts - That fix was reverted in commit c5becf57dd56 due to other hang reports - The revert commit (c5becf57dd56) was even marked with `Cc: stable@vger.kernel.org`, indicating the severity of the issue
3. **Small and Contained Change**: The actual code change is minimal - just removing the `PCI_IRQ_AFFINITY` flag from a single function call. This is a one-line change that doesn't introduce new features or architectural changes.
4. **Well-Tested Fix**: The commit has both "Reviewed-by" and "Tested- by" tags from John Meneghini, indicating it has been properly tested and validated.
5. **No Side Effects Beyond the Fix**: The change simply reverts to non- managed interrupts, allowing all CPUs to be in each HW queue affinity mask. This is a conservative approach that avoids the complexity of trying to properly coordinate CPU-to-queue mappings with interrupt affinities.
6. **Affects Production Systems**: The linked bug report (https://lore.kernel.org/linux- scsi/20250618192427.3845724-1-jmeneghi@redhat.com/) and the previous kernel bugzilla entry (#217599) indicate this affects real production systems experiencing hangs.
7. **Driver-Specific Fix**: The change is confined to the aacraid driver subsystem and doesn't affect other kernel components, minimizing the risk of regression in other areas.
The fix follows stable tree rules perfectly: it fixes an important bug (system hangs), is minimal in scope (one-line change), has low regression risk (reverting to simpler interrupt handling), and is confined to a specific driver subsystem.
drivers/scsi/aacraid/comminit.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/aacraid/comminit.c b/drivers/scsi/aacraid/comminit.c index 28cf18955a08..726c8531b7d3 100644 --- a/drivers/scsi/aacraid/comminit.c +++ b/drivers/scsi/aacraid/comminit.c @@ -481,8 +481,7 @@ void aac_define_int_mode(struct aac_dev *dev) pci_find_capability(dev->pdev, PCI_CAP_ID_MSIX)) { min_msix = 2; i = pci_alloc_irq_vectors(dev->pdev, - min_msix, msi_count, - PCI_IRQ_MSIX | PCI_IRQ_AFFINITY); + min_msix, msi_count, PCI_IRQ_MSIX); if (i > 0) { dev->msi_enabled = 1; msi_count = i;
From: Masahiro Yamada masahiroy@kernel.org
[ Upstream commit f72ed4c6a375e52a3f4b75615e4a89d29d8acea7 ]
If gtk_tree_model_get_iter() fails, gtk_tree_path_free() is not called.
Signed-off-by: Masahiro Yamada masahiroy@kernel.org Acked-by: Randy Dunlap rdunlap@infradead.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Based on my analysis of the commit and examination of the code, here is my assessment:
**Backport Status: YES**
## Extensive Analysis:
### 1. **Nature of the Bug** The commit fixes a clear memory leak in the `renderer_edited()` function in scripts/kconfig/gconf.c. The function allocates a GtkTreePath object using `gtk_tree_path_new_from_string()` at line 782, but if `gtk_tree_model_get_iter()` fails on line 788, the function returns early without calling `gtk_tree_path_free()`, causing a memory leak.
### 2. **Bug Impact** - **Resource leak**: Every time a user attempts to edit a value in the GTK-based kernel configuration tool (gconfig) and the operation fails to get the iterator, memory is leaked. - **User-facing impact**: While gconfig is not used by all kernel users, those who do use it for configuring the kernel could experience memory leaks during interactive configuration sessions. - **Accumulation potential**: In a long configuration session with multiple failed edits, these leaks could accumulate.
### 3. **Fix Analysis** The fix is minimal and straightforward: - Changes the early `return` to a `goto free` statement - Adds a `free:` label before the existing `gtk_tree_path_free(path)` call - This ensures the allocated path is always freed, whether the function succeeds or fails
### 4. **Risk Assessment** - **Minimal risk**: The change only affects the error path and ensures proper cleanup - **No functional changes**: The fix doesn't alter any program logic, it only adds proper resource cleanup - **Well-contained**: The change is limited to a single function in the gconfig tool - **Standard pattern**: Using goto for cleanup is a common and accepted pattern in kernel code
### 5. **Stable Tree Criteria Compliance** The commit meets stable tree requirements: - ✓ Fixes a real bug (memory leak) - ✓ Small and contained (2 lines changed) - ✓ No new features or architectural changes - ✓ Clear and obvious correctness - ✓ Minimal regression risk
### 6. **Historical Context** Looking at the git history, there have been multiple memory leak fixes in the kconfig subsystem (e.g., commits a409fc1463d6, ae1eff0349f2, fbac5977d81c), indicating this is an area where such fixes are considered important and regularly backported.
### 7. **Code Pattern Analysis** Examining other uses of `gtk_tree_model_get_iter()` in the same file shows that other call sites don't have this issue because they either: - Don't allocate resources before the call (lines 902, 962, 1015) - Or are in different contexts where the path is managed differently
This makes the fix in `renderer_edited()` particularly important as it's the only place with this specific leak pattern.
The commit should be backported to stable kernels to ensure users of the gconfig tool don't experience memory leaks during kernel configuration sessions.
scripts/kconfig/gconf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/kconfig/gconf.c b/scripts/kconfig/gconf.c index abe4cfe66b14..0caf0ced13df 100644 --- a/scripts/kconfig/gconf.c +++ b/scripts/kconfig/gconf.c @@ -748,7 +748,7 @@ static void renderer_edited(GtkCellRendererText * cell, struct symbol *sym;
if (!gtk_tree_model_get_iter(model2, &iter, path)) - return; + goto free;
gtk_tree_model_get(model2, &iter, COL_MENU, &menu, -1); sym = menu->sym; @@ -760,6 +760,7 @@ static void renderer_edited(GtkCellRendererText * cell,
update_tree(&rootmenu, NULL);
+free: gtk_tree_path_free(path); }
From: Maurizio Lombardi mlombard@redhat.com
[ Upstream commit 6e0f6aa44b68335df404a2df955055f416b5f2aa ]
Fix target_parse_pr_out_transport_id() to return a string representing the transport ID in a human-readable format (e.g., naa.xxxxxxxx...) for various SCSI protocol types (SAS, FCP, SRP, SBP).
Previously, the function returned a pointer to the raw binary buffer, which was incorrectly compared against human-readable strings, causing comparisons to fail. Now, the function writes a properly formatted string into a buffer provided by the caller. The output format depends on the transport protocol:
* SAS: 64-bit identifier, "naa." prefix. * FCP: 64-bit identifier, colon separated values. * SBP: 64-bit identifier, no prefix. * SRP: 128-bit identifier, "0x" prefix. * iSCSI: IQN string.
Signed-off-by: Maurizio Lombardi mlombard@redhat.com Link: https://lore.kernel.org/r/20250714133738.11054-1-mlombard@redhat.com Reviewed-by: Dmitry Bogdanov d.bogdanov@yadro.com Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
**Backport Status: YES**
This commit should be backported to stable kernel trees. Here's my extensive analysis:
## Bug Fix Nature
This commit fixes a **critical functional bug** in the SCSI target subsystem's Persistent Reservation (PR) handling. The bug causes PR operations to fail when comparing transport IDs, which is a core functionality for SCSI target implementations.
## Technical Analysis of the Bug
1. **Original Problem**: The function `target_parse_pr_out_transport_id()` was returning a pointer to raw binary data (`buf + offset`) instead of a human-readable string representation. This raw binary data was then incorrectly compared against human-readable string formats in callers.
2. **Impact on Functionality**: - In `core_scsi3_decode_spec_i_port()` at line 1610-1611, the code calls `__core_tpg_get_initiator_node_acl(tmp_tpg, i_str)` where `i_str` was previously pointing to binary data - The function `__core_tpg_get_initiator_node_acl()` expects a human- readable initiator string (like "naa.1234567890abcdef" for SAS) - This mismatch would cause the lookup to fail, breaking PR operations
3. **Protocols Affected**: The bug affects multiple SCSI transport protocols: - SAS (SCSI_PROTOCOL_SAS) - Fibre Channel (SCSI_PROTOCOL_FCP) - SRP (SCSI_PROTOCOL_SRP) - SBP (SCSI_PROTOCOL_SBP) - iSCSI (SCSI_PROTOCOL_ISCSI)
## Fix Implementation
The fix properly converts binary transport IDs to their expected string formats: - **SAS**: Converts 8 bytes to "naa.XXXXXXXXXXXX" format - **FCP**: Converts to colon-separated format using `%8phC` - **SRP**: Converts 16 bytes to "0x" prefixed hex string - **SBP**: Converts to plain hex string - **iSCSI**: Already handled strings correctly, but API updated for consistency
## Stable Backport Criteria
This commit meets several key stable tree criteria:
1. **Fixes a Real Bug**: Yes - PR operations would fail for non-iSCSI transports 2. **Small and Contained**: The fix is localized to transport ID parsing functions 3. **No New Features**: Only fixes existing functionality 4. **Minimal Risk**: Changes are straightforward format conversions 5. **Important for Users**: PR is a critical feature for enterprise storage environments 6. **No Architectural Changes**: Simple bug fix without design changes
## Additional Evidence
Looking at the commit history, there have been other PR-related fixes recently (e.g., `d8ab68bdb294` fixing a NULL pointer dereference), indicating this is an actively maintained critical subsystem where bugs need to be fixed in stable kernels.
The fact that this went unnoticed suggests it affects less common code paths, but when triggered, it would completely break PR functionality for affected transport types - a serious issue for production storage systems relying on persistent reservations for cluster coordination.
drivers/target/target_core_fabric_lib.c | 63 +++++++++++++++++++------ drivers/target/target_core_internal.h | 4 +- drivers/target/target_core_pr.c | 18 +++---- 3 files changed, 60 insertions(+), 25 deletions(-)
diff --git a/drivers/target/target_core_fabric_lib.c b/drivers/target/target_core_fabric_lib.c index 43f47e3aa448..ec7bc6e30228 100644 --- a/drivers/target/target_core_fabric_lib.c +++ b/drivers/target/target_core_fabric_lib.c @@ -257,11 +257,41 @@ static int iscsi_get_pr_transport_id_len( return len; }
-static char *iscsi_parse_pr_out_transport_id( +static void sas_parse_pr_out_transport_id(char *buf, char *i_str) +{ + char hex[17] = {}; + + bin2hex(hex, buf + 4, 8); + snprintf(i_str, TRANSPORT_IQN_LEN, "naa.%s", hex); +} + +static void srp_parse_pr_out_transport_id(char *buf, char *i_str) +{ + char hex[33] = {}; + + bin2hex(hex, buf + 8, 16); + snprintf(i_str, TRANSPORT_IQN_LEN, "0x%s", hex); +} + +static void fcp_parse_pr_out_transport_id(char *buf, char *i_str) +{ + snprintf(i_str, TRANSPORT_IQN_LEN, "%8phC", buf + 8); +} + +static void sbp_parse_pr_out_transport_id(char *buf, char *i_str) +{ + char hex[17] = {}; + + bin2hex(hex, buf + 8, 8); + snprintf(i_str, TRANSPORT_IQN_LEN, "%s", hex); +} + +static bool iscsi_parse_pr_out_transport_id( struct se_portal_group *se_tpg, char *buf, u32 *out_tid_len, - char **port_nexus_ptr) + char **port_nexus_ptr, + char *i_str) { char *p; int i; @@ -282,7 +312,7 @@ static char *iscsi_parse_pr_out_transport_id( if ((format_code != 0x00) && (format_code != 0x40)) { pr_err("Illegal format code: 0x%02x for iSCSI" " Initiator Transport ID\n", format_code); - return NULL; + return false; } /* * If the caller wants the TransportID Length, we set that value for the @@ -306,7 +336,7 @@ static char *iscsi_parse_pr_out_transport_id( pr_err("Unable to locate ",i,0x" separator" " for Initiator port identifier: %s\n", &buf[4]); - return NULL; + return false; } *p = '\0'; /* Terminate iSCSI Name */ p += 5; /* Skip over ",i,0x" separator */ @@ -339,7 +369,8 @@ static char *iscsi_parse_pr_out_transport_id( } else *port_nexus_ptr = NULL;
- return &buf[4]; + strscpy(i_str, &buf[4], TRANSPORT_IQN_LEN); + return true; }
int target_get_pr_transport_id_len(struct se_node_acl *nacl, @@ -387,33 +418,35 @@ int target_get_pr_transport_id(struct se_node_acl *nacl, } }
-const char *target_parse_pr_out_transport_id(struct se_portal_group *tpg, - char *buf, u32 *out_tid_len, char **port_nexus_ptr) +bool target_parse_pr_out_transport_id(struct se_portal_group *tpg, + char *buf, u32 *out_tid_len, char **port_nexus_ptr, char *i_str) { - u32 offset; - switch (tpg->proto_id) { case SCSI_PROTOCOL_SAS: /* * Assume the FORMAT CODE 00b from spc4r17, 7.5.4.7 TransportID * for initiator ports using SCSI over SAS Serial SCSI Protocol. */ - offset = 4; + sas_parse_pr_out_transport_id(buf, i_str); break; - case SCSI_PROTOCOL_SBP: case SCSI_PROTOCOL_SRP: + srp_parse_pr_out_transport_id(buf, i_str); + break; case SCSI_PROTOCOL_FCP: - offset = 8; + fcp_parse_pr_out_transport_id(buf, i_str); + break; + case SCSI_PROTOCOL_SBP: + sbp_parse_pr_out_transport_id(buf, i_str); break; case SCSI_PROTOCOL_ISCSI: return iscsi_parse_pr_out_transport_id(tpg, buf, out_tid_len, - port_nexus_ptr); + port_nexus_ptr, i_str); default: pr_err("Unknown proto_id: 0x%02x\n", tpg->proto_id); - return NULL; + return false; }
*port_nexus_ptr = NULL; *out_tid_len = 24; - return buf + offset; + return true; } diff --git a/drivers/target/target_core_internal.h b/drivers/target/target_core_internal.h index 408be26d2e9b..20aab1f50565 100644 --- a/drivers/target/target_core_internal.h +++ b/drivers/target/target_core_internal.h @@ -103,8 +103,8 @@ int target_get_pr_transport_id_len(struct se_node_acl *nacl, int target_get_pr_transport_id(struct se_node_acl *nacl, struct t10_pr_registration *pr_reg, int *format_code, unsigned char *buf); -const char *target_parse_pr_out_transport_id(struct se_portal_group *tpg, - char *buf, u32 *out_tid_len, char **port_nexus_ptr); +bool target_parse_pr_out_transport_id(struct se_portal_group *tpg, + char *buf, u32 *out_tid_len, char **port_nexus_ptr, char *i_str);
/* target_core_hba.c */ struct se_hba *core_alloc_hba(const char *, u32, u32); diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c index 70905805cb17..83e172c92238 100644 --- a/drivers/target/target_core_pr.c +++ b/drivers/target/target_core_pr.c @@ -1478,11 +1478,12 @@ core_scsi3_decode_spec_i_port( LIST_HEAD(tid_dest_list); struct pr_transport_id_holder *tidh_new, *tidh, *tidh_tmp; unsigned char *buf, *ptr, proto_ident; - const unsigned char *i_str = NULL; + unsigned char i_str[TRANSPORT_IQN_LEN]; char *iport_ptr = NULL, i_buf[PR_REG_ISID_ID_LEN]; sense_reason_t ret; u32 tpdl, tid_len = 0; u32 dest_rtpi = 0; + bool tid_found;
/* * Allocate a struct pr_transport_id_holder and setup the @@ -1571,9 +1572,9 @@ core_scsi3_decode_spec_i_port( dest_rtpi = tmp_lun->lun_tpg->tpg_rtpi;
iport_ptr = NULL; - i_str = target_parse_pr_out_transport_id(tmp_tpg, - ptr, &tid_len, &iport_ptr); - if (!i_str) + tid_found = target_parse_pr_out_transport_id(tmp_tpg, + ptr, &tid_len, &iport_ptr, i_str); + if (!tid_found) continue; /* * Determine if this SCSI device server requires that @@ -3153,13 +3154,14 @@ core_scsi3_emulate_pro_register_and_move(struct se_cmd *cmd, u64 res_key, struct t10_pr_registration *pr_reg, *pr_res_holder, *dest_pr_reg; struct t10_reservation *pr_tmpl = &dev->t10_pr; unsigned char *buf; - const unsigned char *initiator_str; + unsigned char initiator_str[TRANSPORT_IQN_LEN]; char *iport_ptr = NULL, i_buf[PR_REG_ISID_ID_LEN] = { }; u32 tid_len, tmp_tid_len; int new_reg = 0, type, scope, matching_iname; sense_reason_t ret; unsigned short rtpi; unsigned char proto_ident; + bool tid_found;
if (!se_sess || !se_lun) { pr_err("SPC-3 PR: se_sess || struct se_lun is NULL!\n"); @@ -3278,9 +3280,9 @@ core_scsi3_emulate_pro_register_and_move(struct se_cmd *cmd, u64 res_key, ret = TCM_INVALID_PARAMETER_LIST; goto out; } - initiator_str = target_parse_pr_out_transport_id(dest_se_tpg, - &buf[24], &tmp_tid_len, &iport_ptr); - if (!initiator_str) { + tid_found = target_parse_pr_out_transport_id(dest_se_tpg, + &buf[24], &tmp_tid_len, &iport_ptr, initiator_str); + if (!tid_found) { pr_err("SPC-3 PR REGISTER_AND_MOVE: Unable to locate" " initiator_str from Transport ID\n"); ret = TCM_INVALID_PARAMETER_LIST;
From: Corey Minyard corey@minyard.net
[ Upstream commit 8ffcb7560b4a15faf821df95e3ab532b2b020f8c ]
The source and destination of some strcpy operations was the same. Split out the part of the operations that needed to be done for those particular calls so the unnecessary copy wasn't done.
Reported-by: kernel test robot lkp@intel.com Closes: https://lore.kernel.org/oe-kbuild-all/202506140756.EFXXvIP4-lkp@intel.com/ Signed-off-by: Corey Minyard corey@minyard.net Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
**Backport Status: YES**
This commit is an excellent candidate for backporting to stable kernel trees. Here's my extensive analysis:
## Bug Description and Impact
The commit fixes a critical bug where `strcpy()` operations were copying a string to itself (source and destination being the same). Looking at the original code:
1. In `action_op()` at line 1213: `strcpy(action, inval);` - but when called from `ipmi_wdog_init()` line 1294 with `action_op(action, NULL)`, the first parameter `action` is passed, and if validation passes, it copies `action` to itself.
2. Similar issues in `preaction_op()` line 1237 and `preop_op()` line 1257 when called from initialization.
This undefined behavior could lead to: - Memory corruption - Unpredictable watchdog behavior during initialization - Potential system instability in the IPMI watchdog subsystem
## Fix Analysis
The fix properly refactors the code by: 1. Creating separate `*_set_val()` functions that only validate and set the value variables 2. Modifying the original functions to use these new helpers 3. In `ipmi_wdog_init()`, directly calling the `*_set_val()` functions for validation without the problematic strcpy
This is a minimal, targeted fix that: - Doesn't introduce new features - Maintains existing functionality - Only restructures code to eliminate undefined behavior - Has clear boundaries within the IPMI watchdog driver
## Stable Tree Criteria Met
1. **Fixes a real bug**: Yes - strcpy with same source/destination is undefined behavior 2. **Small and contained**: Yes - changes are limited to one file and involve straightforward refactoring 3. **No major architectural changes**: Correct - only refactors existing functions 4. **Minimal regression risk**: Yes - the logic remains identical, just properly separated 5. **Critical subsystem**: IPMI watchdog is important for system reliability and recovery 6. **Automated detection**: The bug was found by kernel test robot, indicating it's a real issue
## Additional Evidence
- The commit was reported by the kernel test robot with a specific bug report link - The fix is defensive programming that eliminates undefined behavior - IPMI watchdog is used in production servers for system recovery - The bug could manifest differently across compilers/architectures
This meets all stable kernel criteria for backporting as it fixes a concrete bug with minimal risk.
drivers/char/ipmi/ipmi_watchdog.c | 59 ++++++++++++++++++++++--------- 1 file changed, 42 insertions(+), 17 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_watchdog.c b/drivers/char/ipmi/ipmi_watchdog.c index ab759b492fdd..a013ddbf1466 100644 --- a/drivers/char/ipmi/ipmi_watchdog.c +++ b/drivers/char/ipmi/ipmi_watchdog.c @@ -1146,14 +1146,8 @@ static struct ipmi_smi_watcher smi_watcher = { .smi_gone = ipmi_smi_gone };
-static int action_op(const char *inval, char *outval) +static int action_op_set_val(const char *inval) { - if (outval) - strcpy(outval, action); - - if (!inval) - return 0; - if (strcmp(inval, "reset") == 0) action_val = WDOG_TIMEOUT_RESET; else if (strcmp(inval, "none") == 0) @@ -1164,18 +1158,26 @@ static int action_op(const char *inval, char *outval) action_val = WDOG_TIMEOUT_POWER_DOWN; else return -EINVAL; - strcpy(action, inval); return 0; }
-static int preaction_op(const char *inval, char *outval) +static int action_op(const char *inval, char *outval) { + int rv; + if (outval) - strcpy(outval, preaction); + strcpy(outval, action);
if (!inval) return 0; + rv = action_op_set_val(inval); + if (!rv) + strcpy(action, inval); + return rv; +}
+static int preaction_op_set_val(const char *inval) +{ if (strcmp(inval, "pre_none") == 0) preaction_val = WDOG_PRETIMEOUT_NONE; else if (strcmp(inval, "pre_smi") == 0) @@ -1188,18 +1190,26 @@ static int preaction_op(const char *inval, char *outval) preaction_val = WDOG_PRETIMEOUT_MSG_INT; else return -EINVAL; - strcpy(preaction, inval); return 0; }
-static int preop_op(const char *inval, char *outval) +static int preaction_op(const char *inval, char *outval) { + int rv; + if (outval) - strcpy(outval, preop); + strcpy(outval, preaction);
if (!inval) return 0; + rv = preaction_op_set_val(inval); + if (!rv) + strcpy(preaction, inval); + return 0; +}
+static int preop_op_set_val(const char *inval) +{ if (strcmp(inval, "preop_none") == 0) preop_val = WDOG_PREOP_NONE; else if (strcmp(inval, "preop_panic") == 0) @@ -1208,7 +1218,22 @@ static int preop_op(const char *inval, char *outval) preop_val = WDOG_PREOP_GIVE_DATA; else return -EINVAL; - strcpy(preop, inval); + return 0; +} + +static int preop_op(const char *inval, char *outval) +{ + int rv; + + if (outval) + strcpy(outval, preop); + + if (!inval) + return 0; + + rv = preop_op_set_val(inval); + if (!rv) + strcpy(preop, inval); return 0; }
@@ -1245,18 +1270,18 @@ static int __init ipmi_wdog_init(void) { int rv;
- if (action_op(action, NULL)) { + if (action_op_set_val(action)) { action_op("reset", NULL); pr_info("Unknown action '%s', defaulting to reset\n", action); }
- if (preaction_op(preaction, NULL)) { + if (preaction_op_set_val(preaction)) { preaction_op("pre_none", NULL); pr_info("Unknown preaction '%s', defaulting to none\n", preaction); }
- if (preop_op(preop, NULL)) { + if (preop_op_set_val(preop)) { preop_op("preop_none", NULL); pr_info("Unknown preop '%s', defaulting to none\n", preop); }
From: Ranjan Kumar ranjan.kumar@broadcom.com
[ Upstream commit 37c4e72b0651e7697eb338cd1fb09feef472cc1a ]
sas_user_scan() did not fully process wildcard channel scans (SCAN_WILD_CARD) when a transport-specific user_scan() callback was present. Only channel 0 would be scanned via user_scan(), while the remaining channels were skipped, potentially missing devices.
user_scan() invokes updated sas_user_scan() for channel 0, and if successful, iteratively scans remaining channels (1 to shost->max_channel) via scsi_scan_host_selected(). This ensures complete wildcard scanning without affecting transport-specific scanning behavior.
Signed-off-by: Ranjan Kumar ranjan.kumar@broadcom.com Link: https://lore.kernel.org/r/20250624061649.17990-1-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
**Backport Status: YES**
This commit should be backported to stable kernel trees. Here's my detailed analysis:
## Bug Fix Analysis
This commit fixes a **functional bug** in the SAS transport layer where wildcard channel scans (`SCAN_WILD_CARD`) were not working correctly when a transport-specific `user_scan()` callback was present. The bug manifested as:
1. **Incomplete device discovery**: When performing wildcard scans, only channel 0 devices would be scanned via the SAS-specific `sas_user_scan()`, while channels 1 through `max_channel` were completely skipped. 2. **Missing devices**: This could result in SAS devices on non-zero channels not being discovered during rescans, which is a serious issue for storage management.
## Code Changes Analysis
The fix involves two key changes:
1. **Export of `scsi_scan_host_selected()`** in `drivers/scsi/scsi_scan.c:1902`: - This makes the function available to transport modules - Simple one-line addition: `EXPORT_SYMBOL(scsi_scan_host_selected);`
2. **Rewrite of `sas_user_scan()` logic** in `drivers/scsi/scsi_transport_sas.c`: - Refactored to handle three cases properly: - Channel 0: Scan SAS-specific devices only - `SCAN_WILD_CARD`: First scan channel 0 SAS devices, then iterate through channels 1 to `max_channel` using `scsi_scan_host_selected()` - Other channels: Delegate to `scsi_scan_host_selected()` - The new code properly handles multi-channel configurations
## Stable Backport Criteria
This commit meets the stable kernel criteria:
1. **Fixes a real bug**: The inability to discover devices on non-zero channels during wildcard scans is a clear functional bug that affects users.
2. **Small and contained**: The changes are limited to: - One export symbol addition - One function rewrite in the SAS transport layer - Total diff is relatively small (~100 lines)
3. **No architectural changes**: This is a targeted fix that doesn't change any kernel subsystem architecture or APIs.
4. **Low regression risk**: - The changes are confined to the SCSI SAS transport subsystem - The fix preserves existing behavior for non-wildcard scans - Error handling paths remain intact
5. **Important for users**: Multi-channel SAS configurations are common in enterprise storage systems, and the ability to properly rescan all channels is critical for: - Hot-plug scenarios - Device recovery after errors - Storage management operations
## Additional Context
Looking at the commit history, there have been previous issues with SAS scanning (e.g., commit e9dedc13bb11 "scsi: hisi_sas: Fix rescan after deleting a disk"), indicating this is an area where proper functioning is critical and has had issues before.
The fix is straightforward and correct - it ensures that wildcard scans actually scan all channels as intended, not just channel 0. This is essential functionality that should work correctly in stable kernels.
drivers/scsi/scsi_scan.c | 2 +- drivers/scsi/scsi_transport_sas.c | 60 ++++++++++++++++++++++++------- 2 files changed, 49 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 4833b8fe251b..396fcf194b6b 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -1899,7 +1899,7 @@ int scsi_scan_host_selected(struct Scsi_Host *shost, unsigned int channel,
return 0; } - +EXPORT_SYMBOL(scsi_scan_host_selected); static void scsi_sysfs_add_devices(struct Scsi_Host *shost) { struct scsi_device *sdev; diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c index 351b028ef893..d69c7c444a31 100644 --- a/drivers/scsi/scsi_transport_sas.c +++ b/drivers/scsi/scsi_transport_sas.c @@ -40,6 +40,8 @@ #include <scsi/scsi_transport_sas.h>
#include "scsi_sas_internal.h" +#include "scsi_priv.h" + struct sas_host_attrs { struct list_head rphy_list; struct mutex lock; @@ -1683,32 +1685,66 @@ int scsi_is_sas_rphy(const struct device *dev) } EXPORT_SYMBOL(scsi_is_sas_rphy);
- -/* - * SCSI scan helper - */ - -static int sas_user_scan(struct Scsi_Host *shost, uint channel, - uint id, u64 lun) +static void scan_channel_zero(struct Scsi_Host *shost, uint id, u64 lun) { struct sas_host_attrs *sas_host = to_sas_host_attrs(shost); struct sas_rphy *rphy;
- mutex_lock(&sas_host->lock); list_for_each_entry(rphy, &sas_host->rphy_list, list) { if (rphy->identify.device_type != SAS_END_DEVICE || rphy->scsi_target_id == -1) continue;
- if ((channel == SCAN_WILD_CARD || channel == 0) && - (id == SCAN_WILD_CARD || id == rphy->scsi_target_id)) { + if (id == SCAN_WILD_CARD || id == rphy->scsi_target_id) { scsi_scan_target(&rphy->dev, 0, rphy->scsi_target_id, lun, SCSI_SCAN_MANUAL); } } - mutex_unlock(&sas_host->lock); +}
- return 0; +/* + * SCSI scan helper + */ + +static int sas_user_scan(struct Scsi_Host *shost, uint channel, + uint id, u64 lun) +{ + struct sas_host_attrs *sas_host = to_sas_host_attrs(shost); + int res = 0; + int i; + + switch (channel) { + case 0: + mutex_lock(&sas_host->lock); + scan_channel_zero(shost, id, lun); + mutex_unlock(&sas_host->lock); + break; + + case SCAN_WILD_CARD: + mutex_lock(&sas_host->lock); + scan_channel_zero(shost, id, lun); + mutex_unlock(&sas_host->lock); + + for (i = 1; i <= shost->max_channel; i++) { + res = scsi_scan_host_selected(shost, i, id, lun, + SCSI_SCAN_MANUAL); + if (res) + goto exit_scan; + } + break; + + default: + if (channel < shost->max_channel) { + res = scsi_scan_host_selected(shost, channel, id, lun, + SCSI_SCAN_MANUAL); + } else { + res = -EINVAL; + } + break; + } + +exit_scan: + return res; }
From: Artem Sadovnikov a.sadovnikov@ispras.ru
[ Upstream commit b3060198483bac43ec113c62ae3837076f61f5de ]
MLX cap pg_track_log_max_msg_size consists of 5 bits, value of which is used as power of 2 for max_msg_size. This can lead to multiplication overflow between max_msg_size (u32) and integer constant, and afterwards incorrect value is being written to rq_size.
Fix this issue by extending integer constant to u64 type.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Suggested-by: Alex Williamson alex.williamson@redhat.com Signed-off-by: Artem Sadovnikov a.sadovnikov@ispras.ru Reviewed-by: Yishai Hadas yishaih@nvidia.com Link: https://lore.kernel.org/r/20250701144017.2410-2-a.sadovnikov@ispras.ru Signed-off-by: Alex Williamson alex.williamson@redhat.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
**YES**
This commit should be backported to stable kernel trees for the following reasons:
## Critical Integer Overflow Bug Fix
1. **Clear Bug with Security Implications**: The commit fixes a critical integer overflow bug in the VFIO MLX5 driver. When `log_max_msg_size` reaches its maximum value (31, as it's a 5-bit field), the calculation `4 * max_msg_size` causes an integer overflow: - `max_msg_size = (1ULL << 31) = 2147483648 (0x80000000)` - `4 * max_msg_size` overflows to 0 when calculated as u32 * int - This results in `rq_size` being incorrectly set, potentially to 0 or a very small value
2. **Introduced by Recent Code**: The vulnerable code was introduced in commit 9c7c5430bca36 ("vfio/mlx5: Align the page tracking max message size with the device capability") from December 2024, which itself has a Fixes tag for commit 79c3cf279926 from 2022. This indicates the affected code exists in stable kernels.
3. **Simple and Contained Fix**: The fix is minimal - just changing `4` to `4ULL` in two places to ensure 64-bit arithmetic: ```c - if (rq_size < 4 * max_msg_size) - rq_size = 4 * max_msg_size; + if (rq_size < 4ULL * max_msg_size) + rq_size = 4ULL * max_msg_size; ```
4. **Affects User-Visible Functionality**: This bug affects VFIO device passthrough for MLX5 devices, specifically the page tracking functionality used for live migration. An incorrect `rq_size` could lead to: - Failed QP (Queue Pair) creation - Memory corruption - System instability during VM migration
5. **Low Risk of Regression**: The change only affects the calculation precision by ensuring 64-bit arithmetic. It doesn't change any logic, APIs, or data structures.
6. **Found by Verification Tools**: The bug was discovered by the Linux Verification Center using SVACE static analysis, indicating it's a real issue that could be triggered in practice.
7. **Reviewed by Maintainers**: The fix was suggested by the VFIO maintainer (Alex Williamson) and reviewed by the MLX5 driver maintainer (Yishai Hadas), showing consensus on the solution.
The commit meets all criteria for stable backporting: it fixes a real bug that affects users, the fix is small and contained, there's minimal risk of regression, and it addresses a potential security/stability issue in virtualization infrastructure.
drivers/vfio/pci/mlx5/cmd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/mlx5/cmd.c b/drivers/vfio/pci/mlx5/cmd.c index 5b919a0b2524..a92b095b90f6 100644 --- a/drivers/vfio/pci/mlx5/cmd.c +++ b/drivers/vfio/pci/mlx5/cmd.c @@ -1523,8 +1523,8 @@ int mlx5vf_start_page_tracker(struct vfio_device *vdev, log_max_msg_size = MLX5_CAP_ADV_VIRTUALIZATION(mdev, pg_track_log_max_msg_size); max_msg_size = (1ULL << log_max_msg_size); /* The RQ must hold at least 4 WQEs/messages for successful QP creation */ - if (rq_size < 4 * max_msg_size) - rq_size = 4 * max_msg_size; + if (rq_size < 4ULL * max_msg_size) + rq_size = 4ULL * max_msg_size;
memset(tracker, 0, sizeof(*tracker)); tracker->uar = mlx5_get_uars_page(mdev);
From: Shankari Anand shankari.ak0208@gmail.com
[ Upstream commit f468992936894c9ce3b1659cf38c230d33b77a16 ]
strncpy() does not guarantee null-termination if the source string is longer than the destination buffer.
Ensure the buffer is explicitly null-terminated to prevent potential string overflows or undefined behavior.
Signed-off-by: Shankari Anand shankari.ak0208@gmail.com Signed-off-by: Masahiro Yamada masahiroy@kernel.org Acked-by: Randy Dunlap rdunlap@infradead.org Tested-by: Randy Dunlap rdunlap@infradead.org Tested-by: Nicolas Schier n.schier@avm.de Acked-by: Nicolas Schier n.schier@avm.de Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
**Backport Status: YES**
This commit is a clear security/safety fix that should be backported to stable kernel trees. Here's my detailed analysis:
## Code Changes Analysis
The commit adds explicit null termination after `strncpy()` calls in two locations:
1. **scripts/kconfig/nconf.c** (line ~596): - After copying with `strncpy(k_menu_items[index].str, tmp_str, sizeof(k_menu_items[index].str))` - Adds: `k_menu_items[index].str[sizeof(k_menu_items[index].str) - 1] = '\0';`
2. **scripts/kconfig/nconf.gui.c** (line ~361): - After copying with `strncpy(result, init, *result_len)` - Adds: `result[*result_len - 1] = '\0';`
## Why This Should Be Backported
1. **Bug Fix**: This fixes a genuine security issue where `strncpy()` does not guarantee null-termination if the source string equals or exceeds the destination buffer size. This can lead to: - Buffer overruns when the string is later used - Information disclosure (reading past buffer boundaries) - Potential crashes or undefined behavior
2. **Small and Contained**: The fix is minimal - just two single-line additions that ensure null termination. No architectural changes or new features.
3. **Low Risk**: The changes are straightforward defensive programming practices that cannot introduce regressions. They only ensure strings are properly terminated.
4. **Security Impact**: String handling bugs are a common source of security vulnerabilities. While kconfig tools are build-time utilities (not runtime kernel code), they process user-provided configuration data and should handle strings safely.
5. **Meets Stable Criteria**: - Fixes a real bug (improper string termination) - Minimal change (2 lines added) - Obviously correct (standard C string safety practice) - No new functionality
6. **Testing**: The commit has been tested by multiple developers (Randy Dunlap, Nicolas Schier) and acked by them, indicating confidence in the fix.
The defensive null-termination pattern after `strncpy()` is a well- established best practice in C programming to prevent string-related bugs. This type of fix is exactly what stable kernels should include to improve reliability and security without introducing new risks.
scripts/kconfig/nconf.c | 2 ++ scripts/kconfig/nconf.gui.c | 1 + 2 files changed, 3 insertions(+)
diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c index c0b2dabf6c89..ae1fe5f60327 100644 --- a/scripts/kconfig/nconf.c +++ b/scripts/kconfig/nconf.c @@ -593,6 +593,8 @@ static void item_add_str(const char *fmt, ...) tmp_str, sizeof(k_menu_items[index].str));
+ k_menu_items[index].str[sizeof(k_menu_items[index].str) - 1] = '\0'; + free_item(curses_menu_items[index]); curses_menu_items[index] = new_item( k_menu_items[index].str, diff --git a/scripts/kconfig/nconf.gui.c b/scripts/kconfig/nconf.gui.c index 4bfdf8ac2a9a..7206437e784a 100644 --- a/scripts/kconfig/nconf.gui.c +++ b/scripts/kconfig/nconf.gui.c @@ -359,6 +359,7 @@ int dialog_inputbox(WINDOW *main_window, x = (columns-win_cols)/2;
strncpy(result, init, *result_len); + result[*result_len - 1] = '\0';
/* create the windows */ win = newwin(win_lines, win_cols, y, x);
From: Suchit Karunakaran suchitkarunakaran@gmail.com
[ Upstream commit 5ac726653a1029a2eccba93bbe59e01fc9725828 ]
strcpy() performs no bounds checking and can lead to buffer overflows if the input string exceeds the destination buffer size. This patch replaces it with strncpy(), and null terminates the input string.
Signed-off-by: Suchit Karunakaran suchitkarunakaran@gmail.com Reviewed-by: Nicolas Schier nicolas.schier@linux.dev Signed-off-by: Masahiro Yamada masahiroy@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Based on my analysis of the commit and the code context I was able to examine, here's my assessment:
**Backport Status: YES**
## Extensive Explanation:
This commit should be backported to stable kernel trees for the following reasons:
### 1. **Security Bug Fix** The commit fixes a potential buffer overflow vulnerability in the kconfig lxdialog inputbox code. Looking at the code changes: - The original code uses `strcpy(instr, init)` at line 43 without any bounds checking - `instr` points to `dialog_input_result` which is defined as `char dialog_input_result[MAX_LEN + 1]` (line 11) - From dialog.h, `MAX_LEN` is defined as 2048 (line 25) - If `init` string exceeds 2048 characters, it would overflow the buffer
### 2. **Simple and Contained Fix** The fix is minimal and straightforward: ```c - else - strcpy(instr, init); + else { + strncpy(instr, init, sizeof(dialog_input_result) - 1); + instr[sizeof(dialog_input_result) - 1] = '\0'; + } ``` - Replaces unsafe `strcpy()` with bounded `strncpy()` - Properly null-terminates the string to prevent unterminated string issues - Uses `sizeof(dialog_input_result) - 1` to ensure proper bounds
### 3. **Low Risk of Regression** - The change is localized to a single function in the kconfig tool - It doesn't alter the logic flow, only makes the string copy safer - The kconfig lxdialog is used during kernel configuration, not runtime kernel code - The fix maintains the same functionality while adding safety
### 4. **Meets Stable Criteria** According to stable kernel rules, this commit qualifies because it: - Fixes a real bug (buffer overflow vulnerability) - Is obviously correct and tested (has review from Nicolas Schier) - Is small (only 4 lines changed) - Doesn't add new features or change architecture - Has no functional side effects beyond the security fix
### 5. **Potential Security Impact** While this is in the build tools rather than runtime kernel code, buffer overflows in build tools can still be exploited: - Could be triggered by malicious Kconfig files - Could affect kernel developers or automated build systems - Even build-time vulnerabilities should be fixed in stable trees
The commit is a textbook example of a security fix that should be backported - it's small, focused, fixes a clear vulnerability, and has minimal risk of causing regressions.
scripts/kconfig/lxdialog/inputbox.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/scripts/kconfig/lxdialog/inputbox.c b/scripts/kconfig/lxdialog/inputbox.c index 3c6e24b20f5b..5e4a131724f2 100644 --- a/scripts/kconfig/lxdialog/inputbox.c +++ b/scripts/kconfig/lxdialog/inputbox.c @@ -39,8 +39,10 @@ int dialog_inputbox(const char *title, const char *prompt, int height, int width
if (!init) instr[0] = '\0'; - else - strcpy(instr, init); + else { + strncpy(instr, init, sizeof(dialog_input_result) - 1); + instr[sizeof(dialog_input_result) - 1] = '\0'; + }
do_resize: if (getmaxy(stdscr) <= (height - INPUTBOX_HEIGHT_MIN))
From: Keith Busch kbusch@kernel.org
[ Upstream commit b1779e4f209c7ff7e32f3c79d69bca4e3a3a68b6 ]
A large DMA mapping request can loop through dma address pinning for many pages. In cases where THP can not be used, the repeated vmf_insert_pfn can be costly, so let the task reschedule as need to prevent CPU stalls. Failure to do so has potential harmful side effects, like increased memory pressure as unrelated rcu tasks are unable to make their reclaim callbacks and result in OOM conditions.
rcu: INFO: rcu_sched self-detected stall on CPU rcu: 36-....: (20999 ticks this GP) idle=b01c/1/0x4000000000000000 softirq=35839/35839 fqs=3538 rcu: hardirqs softirqs csw/system rcu: number: 0 107 0 rcu: cputime: 50 0 10446 ==> 10556(ms) rcu: (t=21075 jiffies g=377761 q=204059 ncpus=384) ... <TASK> ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? walk_system_ram_range+0x63/0x120 ? walk_system_ram_range+0x46/0x120 ? pgprot_writethrough+0x20/0x20 lookup_memtype+0x67/0xf0 track_pfn_insert+0x20/0x40 vmf_insert_pfn_prot+0x88/0x140 vfio_pci_mmap_huge_fault+0xf9/0x1b0 [vfio_pci_core] __do_fault+0x28/0x1b0 handle_mm_fault+0xef1/0x2560 fixup_user_fault+0xf5/0x270 vaddr_get_pfns+0x169/0x2f0 [vfio_iommu_type1] vfio_pin_pages_remote+0x162/0x8e0 [vfio_iommu_type1] vfio_iommu_type1_ioctl+0x1121/0x1810 [vfio_iommu_type1] ? futex_wake+0x1c1/0x260 x64_sys_call+0x234/0x17a0 do_syscall_64+0x63/0x130 ? exc_page_fault+0x63/0x130 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Signed-off-by: Keith Busch kbusch@kernel.org Reviewed-by: Paul E. McKenney paulmck@kernel.org Link: https://lore.kernel.org/r/20250715184622.3561598-1-kbusch@meta.com Signed-off-by: Alex Williamson alex.williamson@redhat.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
**Backport Status: YES**
This commit should be backported to stable kernel trees. Here's my extensive analysis:
## Bug Fix Nature
The commit fixes a critical CPU stall issue that can lead to system instability. The RCU stall trace in the commit message shows: - A 21-second RCU stall (`t=21075 jiffies`) - Over 10 seconds of CPU time consumed (`cputime: 10556ms`) - The stall originates from `vfio_pin_pages_remote()` during large DMA mapping operations
This is a serious bug that affects system reliability and can cascade into OOM conditions as mentioned: "increased memory pressure as unrelated rcu tasks are unable to make their reclaim callbacks and result in OOM conditions."
## Code Change Analysis
The fix is minimal and well-contained: 1. **Single line addition**: The patch adds only `cond_resched()` call at line 654 (after the comment block) 2. **Strategic placement**: Positioned at the beginning of the batch refill loop, before `vaddr_get_pfns()` is called 3. **Clear comment**: The 5-line comment explains exactly why the reschedule is needed
```c + /* + * Large mappings may take a while to repeatedly refill + * the batch, so conditionally relinquish the CPU when + * needed to avoid stalls. + */ + cond_resched(); ```
## Stability and Safety
1. **Low risk**: `cond_resched()` is a standard kernel primitive that only yields CPU if needed 2. **Already used pattern**: My search shows vfio_iommu_type1.c already uses `cond_resched()` in other places, confirming this is an established pattern 3. **No functional changes**: The fix doesn't alter the logic of DMA pinning, it just prevents monopolizing the CPU 4. **Reviewed by RCU maintainer**: Paul E. McKenney's review adds credibility to the fix
## Stable Tree Criteria Compliance
Per stable-kernel-rules.rst, this meets the criteria: - **Fixes a real bug**: CPU stalls and potential OOM are serious issues - **Small change**: Single line addition with comment - **Obviously correct**: Standard solution for long-running loops - **Already tested**: Has been in mainline and reviewed by experts - **No new features**: Pure bug fix, no functionality addition
## Impact Assessment
The bug affects systems performing large DMA mappings through VFIO, particularly when Transparent Huge Pages (THP) cannot be used. This is common in: - Virtual machine device passthrough - GPU/accelerator passthrough scenarios - Large memory pinning operations
Without this fix, affected systems can experience: - RCU stalls leading to system unresponsiveness - Memory pressure and OOM kills - Performance degradation for unrelated tasks
The fix prevents these issues with negligible overhead (conditional reschedule only when needed).
drivers/vfio/vfio_iommu_type1.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c index 1136d7ac6b59..f8d68fe77b41 100644 --- a/drivers/vfio/vfio_iommu_type1.c +++ b/drivers/vfio/vfio_iommu_type1.c @@ -647,6 +647,13 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma, unsigned long vaddr,
while (npage) { if (!batch->size) { + /* + * Large mappings may take a while to repeatedly refill + * the batch, so conditionally relinquish the CPU when + * needed to avoid stalls. + */ + cond_resched(); + /* Empty batch, so refill it. */ ret = vaddr_get_pfns(mm, vaddr, npage, dma->prot, &pfn, batch);
From: Breno Leitao leitao@debian.org
[ Upstream commit ec50ec378e3fd83bde9b3d622ceac3509a60b6b5 ]
During BMC firmware upgrades on live systems, the ipmi_msghandler generates excessive "BMC returned incorrect response" warnings while the BMC is temporarily offline. This can flood system logs in large deployments.
Replace dev_warn() with dev_warn_ratelimited() to throttle these warnings and prevent log spam during BMC maintenance operations.
Signed-off-by: Breno Leitao leitao@debian.org Message-ID: 20250710-ipmi_ratelimit-v1-1-6d417015ebe9@debian.org Signed-off-by: Corey Minyard corey@minyard.net Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
**Backport Status: YES**
This commit is an excellent candidate for backporting to stable kernel trees for the following reasons:
1. **Fixes a Real User-Impacting Bug**: The commit addresses log flooding during BMC firmware upgrades or when BMC is temporarily offline. This is a practical operational issue that affects production systems, especially in large deployments where BMC maintenance is routine.
2. **Minimal and Safe Change**: The change is trivial - simply replacing `dev_warn()` with `dev_warn_ratelimited()`. This is: - A single-line change - Uses well-established kernel infrastructure (ratelimited logging) - Has no functional impact on the IPMI driver's operation - Cannot introduce regressions in driver functionality
3. **Clear Problem Statement**: The commit message clearly describes a specific scenario (BMC firmware upgrades) where excessive "BMC returned incorrect response" warnings flood system logs. This is a documented, reproducible issue.
4. **Follows Established Pattern**: The kernel already has precedent for this type of fix. Commit ca8c1c53b03b ("ipmi: rate limit ipmi smi_event failure message") from kernel v5.15 made similar changes to address log flooding in the same subsystem, and that was successfully integrated into stable trees.
5. **Low Risk**: The change only affects logging behavior, not the actual handling of IPMI messages. The error path (goto return_unspecified) remains unchanged, maintaining the same error handling logic.
6. **Addresses Operational Concerns**: In production environments with many servers, BMC maintenance is common. Without rate limiting, logs can grow excessively, potentially: - Filling up disk space - Making real issues harder to spot - Degrading system performance due to excessive logging I/O
7. **Code Context Shows Repeated Condition**: Looking at the code path (lines 4604-4615), this warning triggers when the BMC response doesn't match the expected NetFN and Command. During BMC firmware updates or reboots, this mismatch can occur repeatedly until the BMC comes back online, making rate limiting essential.
The change meets all criteria for stable backporting: it fixes a bug affecting users, is small and contained, has minimal risk of regression, and addresses a clear operational problem without introducing new features or architectural changes.
drivers/char/ipmi/ipmi_msghandler.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c index 064944ae9fdc..8e9050f99e9e 100644 --- a/drivers/char/ipmi/ipmi_msghandler.c +++ b/drivers/char/ipmi/ipmi_msghandler.c @@ -4607,10 +4607,10 @@ static int handle_one_recv_msg(struct ipmi_smi *intf, * The NetFN and Command in the response is not even * marginally correct. */ - dev_warn(intf->si_dev, - "BMC returned incorrect response, expected netfn %x cmd %x, got netfn %x cmd %x\n", - (msg->data[0] >> 2) | 1, msg->data[1], - msg->rsp[0] >> 2, msg->rsp[1]); + dev_warn_ratelimited(intf->si_dev, + "BMC returned incorrect response, expected netfn %x cmd %x, got netfn %x cmd %x\n", + (msg->data[0] >> 2) | 1, msg->data[1], + msg->rsp[0] >> 2, msg->rsp[1]);
goto return_unspecified; }
linux-stable-mirror@lists.linaro.org