From: Matthias Schiffer matthias.schiffer@tq-group.com

[ Upstream commit 3f61783920504b2cf99330b372d82914bb004d8e ]

am33xx.dtsi has the same clock setup as am35xx.dtsi, setting ti,no-reset-on-init and ti,no-idle on timer1_target and timer2_target, so AM33 needs the same workaround as AM35 to avoid ti-sysc probe failing on certain target modules.

Signed-off-by: Matthias Schiffer matthias.schiffer@tq-group.com Signed-off-by: Alexander Stein alexander.stein@ew.tq-group.com Link: https://lore.kernel.org/r/20250825131114.2206804-1-alexander.stein@ew.tq-gro... Signed-off-by: Kevin Hilman khilman@baylibre.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

# Commit Analysis: ti-sysc: allow OMAP2 and OMAP4 timers to be reserved on AM33xx

## 1. Commit Message Analysis

**Subject/Body**: The commit addresses ti-sysc probe failures on AM33xx platforms (commonly used in BeagleBone and industrial embedded systems). The commit explains that AM33xx has the same clock setup as AM35xx (with `ti,no-reset-on-init` and `ti,no-idle` on timer targets), so it needs the same workaround.

**Notable absence**: No `Cc: stable@vger.kernel.org` or `Fixes:` tag. The maintainers didn't explicitly mark this for stable backporting.

## 2. Code Change Analysis

The changes are minimal and well-contained:

1. **New enum value**: Adds `SOC_AM33` to `enum sysc_soc` at `drivers/bus/ti-sysc.c:51` 2. **SoC detection**: Adds `SOC_FLAG("AM33*", SOC_AM33)` to `sysc_soc_match[]` 3. **Logic extension in `sysc_check_active_timer()`**: - Converts if/else to switch statement - Adds `SOC_AM33` case alongside existing `SOC_3430` and `SOC_AM35` to return `-ENXIO`

**Technical mechanism**: When a timer has both `SYSC_QUIRK_NO_RESET_ON_INIT` and `SYSC_QUIRK_NO_IDLE` quirks set (indicating it's likely in use by the system timer driver), and the SoC is AM33/AM35/3430, the function returns `-ENXIO` allowing the timer to be "reserved" and preventing probe failure.

## 3. Classification

This falls under the **QUIRKS and WORKAROUNDS** exception category: - Extends an existing hardware-specific workaround to similar hardware - Fixes probe failures on real devices - Follows an established pattern in the driver for handling SoC-specific timer behavior

## 4. Scope and Risk Assessment

**Size**: Very small (~20 lines, 1 file) **Subsystem**: ti-sysc bus driver (OMAP/TI platform-specific) **Complexity**: Low - straightforward extension of existing logic **Risk**: Very low - only affects AM33xx platforms, doesn't change behavior for any other SoC

The switch statement change is a cosmetic improvement that makes the code cleaner while adding the new case.

## 5. User Impact

**Who is affected**: Users of AM33xx-based systems (BeagleBone Black, industrial AM335x boards) **Severity**: Probe failures prevent proper hardware initialization, which can be significant for embedded systems **Prevalence**: AM33xx is a widely-deployed platform

## 6. Stability Indicators

- Multiple signed-off-by tags (Matthias Schiffer, Alexander Stein, Kevin Hilman) - Proper review via lore.kernel.org - Follows established patterns in the codebase (SOC_AM35 workaround already existed)

## 7. Dependency Check

The commit is self-contained. The required infrastructure (SOC detection mechanism, timer quirk handling) already exists in the driver. The only addition is a new enum value and extending the switch case.

## Summary Assessment

**Pros**: - Fixes real probe failures on commonly-used embedded platforms - Very small, contained change with low regression risk - Extends existing well-tested workaround to similar hardware - Falls under the "quirks/workarounds" exception for stable

**Cons**: - No explicit `Cc: stable` tag from maintainers - No `Fixes:` tag to identify when the bug was introduced - Adds new code (enum value) rather than purely fixing existing code

**Risk vs Benefit**: The risk is very low (only affects AM33xx platforms, extends existing logic). The benefit is meaningful for AM33xx users who would otherwise hit probe failures. This type of platform- specific quirk extension is common and safe.

## Verdict

This is a small, well-contained fix that extends an existing hardware workaround to similar hardware (AM33xx). While it lacks explicit stable tags, it meets the criteria for the "quirks and workarounds" exception. The fix prevents probe failures on a widely-used embedded platform with minimal regression risk. The pattern of extending SoC-specific workarounds to similar SoCs is well-established and safe.

**YES**

drivers/bus/ti-sysc.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c index 5566ad11399e7..610354ce7f8f0 100644 --- a/drivers/bus/ti-sysc.c +++ b/drivers/bus/ti-sysc.c @@ -48,6 +48,7 @@ enum sysc_soc { SOC_UNKNOWN, SOC_2420, SOC_2430, + SOC_AM33, SOC_3430, SOC_AM35, SOC_3630, @@ -2912,6 +2913,7 @@ static void ti_sysc_idle(struct work_struct *work) static const struct soc_device_attribute sysc_soc_match[] = { SOC_FLAG("OMAP242*", SOC_2420), SOC_FLAG("OMAP243*", SOC_2430), + SOC_FLAG("AM33*", SOC_AM33), SOC_FLAG("AM35*", SOC_AM35), SOC_FLAG("OMAP3[45]*", SOC_3430), SOC_FLAG("OMAP3[67]*", SOC_3630), @@ -3117,10 +3119,15 @@ static int sysc_check_active_timer(struct sysc *ddata) * can be dropped if we stop supporting old beagleboard revisions * A to B4 at some point. */ - if (sysc_soc->soc == SOC_3430 || sysc_soc->soc == SOC_AM35) + switch (sysc_soc->soc) { + case SOC_AM33: + case SOC_3430: + case SOC_AM35: error = -ENXIO; - else + break; + default: error = -EBUSY; + }

if ((ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT) && (ddata->cfg.quirks & SYSC_QUIRK_NO_IDLE))

From: Li Qiang liqiang01@kylinos.cn

[ Upstream commit 7aa31ee9ec92915926e74731378c009c9cc04928 ]

The VIA watchdog driver uses allocate_resource() to reserve a MMIO region for the watchdog control register. However, the allocated resource was not given a name, which causes the kernel resource tree to contain an entry marked as "<BAD>" under /proc/iomem on x86 platforms.

During boot, this unnamed resource can lead to a critical hang because subsequent resource lookups and conflict checks fail to handle the invalid entry properly.

Signed-off-by: Li Qiang liqiang01@kylinos.cn Reviewed-by: Guenter Roeck linux@roeck-us.net Signed-off-by: Guenter Roeck linux@roeck-us.net Signed-off-by: Wim Van Sebroeck wim@linux-watchdog.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Analysis Summary

### 1. COMMIT MESSAGE ANALYSIS

**Subject:** "via_wdt: fix critical boot hang due to unnamed resource allocation" - Uses "fix" language indicating a bug fix - Claims "critical boot hang" - a severe user-impacting issue - Affects VIA chipset watchdog driver

**Tags analysis:** - **Missing:** No "Cc: stable@vger.kernel.org" tag - **Missing:** No "Fixes:" tag - **Present:** Reviewed-by: Guenter Roeck (well-respected watchdog/hwmon maintainer) - **Present:** Signed-off by both watchdog maintainers (Guenter Roeck and Wim Van Sebroeck)

### 2. CODE CHANGE ANALYSIS

The fix is a **single line addition**: ```c wdt_res.name = "via_wdt"; ```

**The bug mechanism:** 1. `wdt_res` is declared as a static `struct resource` without initialization at line 67 2. `allocate_resource()` is called without the resource having a name set 3. This results in a NULL `name` field, shown as `<BAD>` in `/proc/iomem` 4. The kernel's resource code in `kernel/resource.c:141` shows: `r->name ? r->name : "<BAD>"`

**Why this is needed:** - Other watchdog drivers (e.g., `f71808e_wdt.c`) properly set `wdt_res.name = "superio port"` - `struct resource` has a `name` field that should always be populated

### 3. CLASSIFICATION

- **Type:** Bug fix (not new feature) - **Severity:** The commit claims "critical boot hang" - though the exact mechanism isn't fully clear from code inspection, unnamed resources can cause problems in resource lookup/conflict resolution paths - **Scope:** Single driver, single line

### 4. SCOPE AND RISK ASSESSMENT

| Factor | Assessment | |--------|------------| | Lines changed | 1 | | Files touched | 1 | | Complexity | Extremely low | | Risk of regression | **Zero** - adding a name to a resource cannot cause problems | | Self-contained | Yes, no dependencies |

### 5. USER IMPACT

- **Affected users:** VIA chipset hardware with watchdog (relatively rare, older hardware) - **Severity if bug hits:** Boot hang (critical) - **Bug age:** Present since driver was introduced in 2011 (`dc3c56b703dad`)

### 6. STABILITY INDICATORS

- **Reviewed-by:** Guenter Roeck - respected maintainer - **Correctness:** Obviously correct - other drivers do the same thing - **Testing:** Implied through maintainer review

### 7. DEPENDENCY CHECK

- **No dependencies** - completely self-contained - **Driver exists in all stable trees** - since 2011

## Risk vs Benefit Analysis

**Benefits:** - Fixes potential boot hang for affected users - Fixes incorrect `/proc/iomem` display (`<BAD>` entries) - Brings via_wdt in line with other watchdog drivers

**Risks:** - **None** - setting a resource name is a standard, safe operation

## Concerns

1. **No explicit stable request:** The maintainers didn't add `Cc: stable@vger.kernel.org` 2. **Boot hang claim verification:** The exact mechanism for the boot hang isn't easily traced in code, though I trust the reporter/maintainers' assessment 3. **Limited scope:** Only affects VIA chipset users (small population)

## Conclusion

This commit **should be backported** to stable kernels. Despite the missing stable tag, it meets all stable criteria:

1. ✅ **Obviously correct** - trivial one-line fix matching other drivers' patterns 2. ✅ **Fixes a real bug** - unnamed resources are incorrect and can cause issues 3. ✅ **Small and contained** - one line in one file 4. ✅ **No new features** - just fixing existing code 5. ✅ **Zero regression risk** - adding a name cannot break anything 6. ✅ **Maintainer reviewed** - Guenter Roeck reviewed

The fix is so trivially safe that even if the boot hang is rare, there is no downside to including it in stable.

**YES**

drivers/watchdog/via_wdt.c | 1 + 1 file changed, 1 insertion(+)

diff --git a/drivers/watchdog/via_wdt.c b/drivers/watchdog/via_wdt.c index d647923d68fed..f555763926518 100644 --- a/drivers/watchdog/via_wdt.c +++ b/drivers/watchdog/via_wdt.c @@ -165,6 +165,7 @@ static int wdt_probe(struct pci_dev *pdev, dev_err(&pdev->dev, "cannot enable PCI device\n"); return -ENODEV; } + wdt_res.name = "via_wdt";

/* * Allocate a MMIO region which contains watchdog control register

From: Yuezhang Mo Yuezhang.Mo@sony.com

[ Upstream commit 4e163c39dd4e70fcdce948b8774d96e0482b4a11 ]

xfstests generic/363 was failing due to unzeroed post-EOF page cache that allowed mmap writes beyond EOF to become visible after file extension.

For example, in following xfs_io sequence, 0x22 should not be written to the file but would become visible after the extension:

xfs_io -f -t -c "pwrite -S 0x11 0 8" \ -c "mmap 0 4096" \ -c "mwrite -S 0x22 32 32" \ -c "munmap" \ -c "pwrite -S 0x33 512 32" \ $testfile

This violates the expected behavior where writes beyond EOF via mmap should not persist after the file is extended. Instead, the extended region should contain zeros.

Fix this by using truncate_pagecache() to truncate the page cache after the current EOF when extending the file.

Signed-off-by: Yuezhang Mo Yuezhang.Mo@sony.com Signed-off-by: Namjae Jeon linkinjeon@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: exfat: zero out post-EOF page cache on file extension

### 1. COMMIT MESSAGE ANALYSIS

**Problem Description**: - xfstests generic/363 failing due to unzeroed post-EOF page cache - mmap writes beyond EOF become visible after file extension - This violates expected POSIX behavior where extended regions should contain zeros

**Keywords**: "failing", "fix" - indicates this fixes a real bug

**Tags**: - No `Cc: stable@vger.kernel.org` tag - No `Fixes:` tag - Signed-off-by from exfat maintainer (Namjae Jeon)

### 2. CODE CHANGE ANALYSIS

The fix adds `truncate_pagecache()` calls in two locations:

**Change 1 - `exfat_cont_expand()` (~line 30)**: ```c + truncate_pagecache(inode, i_size_read(inode)); ``` This truncates page cache to current EOF when expanding a file, invalidating any stale data that may have been written beyond EOF via mmap.

**Change 2 - `exfat_file_write_iter()` (~line 645)**: ```c + if (pos > i_size_read(inode)) + truncate_pagecache(inode, i_size_read(inode)); ``` This truncates page cache before writes that extend the file, with a conditional check to only run when write position exceeds current file size.

**Technical mechanism of the bug**: - User mmaps a file and writes beyond EOF into page cache - These writes don't persist (they're beyond EOF) - Later, when the file is extended, the stale page cache with those beyond-EOF writes becomes part of the valid file content - Result: data that should never have persisted becomes visible

**Why the fix works**: `truncate_pagecache()` invalidates all page cache beyond the specified position, ensuring any stale post-EOF data is discarded before extending the file.

### 3. CLASSIFICATION

- **Type**: Bug fix for **data integrity issue** - **Category**: Filesystem semantics violation - **Not an exception case**: Not a device ID, quirk, DT update, or build fix

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed**: +3 lines (very small) - **Files touched**: 1 file (fs/exfat/file.c) - **Complexity**: Low - uses standard kernel APIs - **Subsystem maturity**: exfat is relatively mature (in mainline since 5.7) - **Regression risk**: LOW - `truncate_pagecache()` is a well-tested standard API used by many filesystems for this exact purpose

### 5. USER IMPACT

- **Who is affected**: Users of exfat filesystem (common on SD cards, USB drives, camera media) - **Severity**: Moderate to high - data integrity violation - **Reproducibility**: Reproducible via xfstests generic/363, specific mmap usage patterns - **Real-world impact**: Could cause unexpected data appearing in files, data corruption scenarios

### 6. STABILITY INDICATORS

- **Tested**: Yes - via xfstests generic/363 (standard filesystem test suite) - **Reviewed**: Has maintainer sign-off (Namjae Jeon) - **Pattern**: Fix follows the same approach used by other mature filesystems (ext4, xfs, etc.) for handling post-EOF page cache

### 7. DEPENDENCY CHECK

- Uses only existing kernel APIs (`truncate_pagecache()`, `i_size_read()`) - No dependencies on other commits - Functions being modified (`exfat_cont_expand`, `exfat_file_write_iter`) exist in stable kernels

---

## Summary

**What problem does this solve?** Data integrity bug where mmap writes beyond EOF incorrectly persist after file extension, violating filesystem semantics.

**Does it meet stable kernel rules?** - ✅ Obviously correct - uses standard pattern from other filesystems - ✅ Fixes real bug - detected by xfstests, affects real users - ✅ Important issue - data integrity is critical for filesystems - ✅ Small and contained - 3 lines, 1 file - ✅ No new features - pure bug fix - ✅ Should apply cleanly - no dependencies

**Risk vs Benefit:** - **Risk**: Very low - small change using well-tested APIs - **Benefit**: Fixes data integrity issue on widely-used filesystem (exfat used on removable media)

**Concerns:** - No explicit `Cc: stable` tag, but maintainer may not have considered it necessary - No `Fixes:` tag, so unclear when bug was introduced (likely present since exfat's initial inclusion)

This is a clear-cut data integrity bug fix with minimal risk. The fix is small, surgical, uses standard kernel APIs, and follows the same pattern used by mature filesystems like ext4 and xfs. Data integrity issues in filesystems should be fixed in stable trees to protect users from silent data corruption.

**YES**

fs/exfat/file.c | 5 +++++ 1 file changed, 5 insertions(+)

diff --git a/fs/exfat/file.c b/fs/exfat/file.c index adc37b4d7fc2d..536c8078f0c19 100644 --- a/fs/exfat/file.c +++ b/fs/exfat/file.c @@ -25,6 +25,8 @@ static int exfat_cont_expand(struct inode *inode, loff_t size) struct exfat_sb_info *sbi = EXFAT_SB(sb); struct exfat_chain clu;

+ truncate_pagecache(inode, i_size_read(inode)); + ret = inode_newsize_ok(inode, size); if (ret) return ret; @@ -639,6 +641,9 @@ static ssize_t exfat_file_write_iter(struct kiocb *iocb, struct iov_iter *iter)

inode_lock(inode);

+ if (pos > i_size_read(inode)) + truncate_pagecache(inode, i_size_read(inode)); + valid_size = ei->valid_size;

ret = generic_write_checks(iocb, iter);

From: Jinhui Guo guojinhui.liam@bytedance.com

[ Upstream commit 6bd30d8fc523fb880b4be548e8501bc0fe8f42d4 ]

channel_handler() sets intf->channels_ready to true but never clears it, so __scan_channels() skips any rescan. When the BMC firmware changes a rescan is required. Allow it by clearing the flag before starting a new scan.

Signed-off-by: Jinhui Guo guojinhui.liam@bytedance.com Message-ID: 20250930074239.2353-3-guojinhui.liam@bytedance.com Signed-off-by: Corey Minyard corey@minyard.net Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Analysis of IPMI Channel Rescan Fix

### 1. COMMIT MESSAGE ANALYSIS

**Subject:** "ipmi: Fix __scan_channels() failing to rescan channels" - clear bug fix indication.

**Problem described:** - `channel_handler()` sets `intf->channels_ready = true` but never clears it - This causes `__scan_channels()` to skip rescans - When BMC firmware changes, a rescan is required but doesn't happen

**Tags check:** - No "Cc: stable@vger.kernel.org" tag - No "Fixes:" tag - Signed off by IPMI maintainer Corey Minyard

### 2. CODE CHANGE ANALYSIS

The fix adds a `bool rescan` parameter to `__scan_channels()`:

```c static int __scan_channels(struct ipmi_smi *intf, struct ipmi_device_id *id, bool rescan) { if (rescan) { /* Clear channels_ready to force channels rescan. */ intf->channels_ready = false; } ... } ```

**Call site updates:** - `ipmi_add_smi()`: `__scan_channels(intf, &id, false)` - initial scan - `__bmc_get_device_id()` after BMC re-registration: `__scan_channels(intf, &id, false)` - fresh state - `__bmc_get_device_id()` when version info changes: `__scan_channels(intf, &bmc->fetch_id, true)` - rescan needed

**Bug mechanism:** When BMC firmware changes and `__bmc_get_device_id()` detects version info differences, it calls `__scan_channels()` to update channel information. However, since `channels_ready` was already set `true` from the initial scan, the rescan logic is skipped, leaving stale channel information.

### 3. CLASSIFICATION

- **Type:** Bug fix (not a feature) - **Category:** Functional bug in existing driver logic - **Security:** No security implications

### 4. SCOPE AND RISK ASSESSMENT

**Scope:** - 1 file changed: `drivers/char/ipmi/ipmi_msghandler.c` - ~15 lines of actual changes (mostly parameter additions) - Localized to the `__scan_channels()` function and its callers

**Risk:** LOW - The logic is simple and obvious: clear a boolean flag before rescanning - No complex interactions or side effects - The differentiation between initial scan (`false`) and rescan (`true`) is well-reasoned

### 5. USER IMPACT

**Affected users:** - Servers with IPMI/BMC interfaces (common in enterprise/datacenter environments) - Users who update BMC firmware while the system is running

**Impact without fix:** - After BMC firmware updates, IPMI channel information becomes stale - System management through IPMI may malfunction - Users must reboot to get correct channel information

**Severity:** Medium - affects functionality, not crashes or data corruption

### 6. STABILITY INDICATORS

- Signed off by IPMI subsystem maintainer - The fix logic is straightforward and verifiable by inspection - No complex algorithmic changes

### 7. DEPENDENCY CHECK

- Self-contained fix with no dependencies on other commits - `ipmi_msghandler.c` exists in all stable trees (mature driver) - The affected functions (`__scan_channels`, `channel_handler`) exist in stable kernels

### Risk vs Benefit Assessment

**Benefits:** - Fixes real-world bug: BMC firmware updates are common maintenance operations - Small, surgical fix with minimal code changes - IPMI is critical for server management in enterprise environments

**Risks:** - Very low - the change is obviously correct - Adding a parameter and clearing a flag is straightforward - No behavioral changes to working code paths (initial scan unchanged)

### Concerns

1. **No Fixes: tag** - Cannot determine when bug was introduced, making it harder to know which stable versions need it 2. **No explicit Cc: stable** - Author didn't request backport 3. **Specific scenario** - Only affects systems where BMC firmware changes at runtime

### Conclusion

This commit fixes a legitimate functional bug where IPMI channel rescanning fails after BMC firmware changes. The fix is: - **Obviously correct**: Clear a "ready" flag before rescanning - **Small and contained**: ~15 lines in one file - **Fixes a real bug**: Users who update BMC firmware encounter this - **Low risk**: Simple boolean flag manipulation

While it lacks explicit stable tags, the fix is valuable for enterprise users who rely on IPMI for server management. The change is minimal, the logic is clear, and it restores expected functionality without introducing new features.

**YES**

drivers/char/ipmi/ipmi_msghandler.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c index d3f84deee4513..0a886399f9daf 100644 --- a/drivers/char/ipmi/ipmi_msghandler.c +++ b/drivers/char/ipmi/ipmi_msghandler.c @@ -599,7 +599,8 @@ static void __ipmi_bmc_unregister(struct ipmi_smi *intf); static int __ipmi_bmc_register(struct ipmi_smi *intf, struct ipmi_device_id *id, bool guid_set, guid_t *guid, int intf_num); -static int __scan_channels(struct ipmi_smi *intf, struct ipmi_device_id *id); +static int __scan_channels(struct ipmi_smi *intf, + struct ipmi_device_id *id, bool rescan);

static void free_ipmi_user(struct kref *ref) { @@ -2668,7 +2669,7 @@ static int __bmc_get_device_id(struct ipmi_smi *intf, struct bmc_device *bmc, if (__ipmi_bmc_register(intf, &id, guid_set, &guid, intf_num)) need_waiter(intf); /* Retry later on an error. */ else - __scan_channels(intf, &id); + __scan_channels(intf, &id, false);

if (!intf_set) { @@ -2688,7 +2689,7 @@ static int __bmc_get_device_id(struct ipmi_smi *intf, struct bmc_device *bmc, goto out_noprocessing; } else if (memcmp(&bmc->fetch_id, &bmc->id, sizeof(bmc->id))) /* Version info changes, scan the channels again. */ - __scan_channels(intf, &bmc->fetch_id); + __scan_channels(intf, &bmc->fetch_id, true);

bmc->dyn_id_expiry = jiffies + IPMI_DYN_DEV_ID_EXPIRY;

@@ -3438,10 +3439,17 @@ channel_handler(struct ipmi_smi *intf, struct ipmi_recv_msg *msg) /* * Must be holding intf->bmc_reg_mutex to call this. */ -static int __scan_channels(struct ipmi_smi *intf, struct ipmi_device_id *id) +static int __scan_channels(struct ipmi_smi *intf, + struct ipmi_device_id *id, + bool rescan) { int rv;

+ if (rescan) { + /* Clear channels_ready to force channels rescan. */ + intf->channels_ready = false; + } + if (ipmi_version_major(id) > 1 || (ipmi_version_major(id) == 1 && ipmi_version_minor(id) >= 5)) { @@ -3656,7 +3664,7 @@ int ipmi_add_smi(struct module *owner, }

mutex_lock(&intf->bmc_reg_mutex); - rv = __scan_channels(intf, &id); + rv = __scan_channels(intf, &id, false); mutex_unlock(&intf->bmc_reg_mutex); if (rv) goto out_err_bmc_reg;

From: Josua Mayer josua@solid-run.com

[ Upstream commit f0e6bc0c3ef4b4afb299bd6912586cafd5d864e9 ]

CP110 based platforms rely on the bootloader for pci port initialization. TF-A actively prevents non-uboot re-configuration of pci lanes, and many boards do not have software control over the pci card reset.

If a pci port had link at boot-time and the clock is stopped at a later point, the link fails and can not be recovered.

PCI controller driver probe - and by extension ownership of a driver for the pci clocks - may be delayed especially on large modular kernels, causing the clock core to start disabling unused clocks.

Add the CLK_IGNORE_UNUSED flag to the three pci port's clocks to ensure they are not stopped before the pci controller driver has taken ownership and tested for an existing link.

This fixes failed pci link detection when controller driver probes late, e.g. with arm64 defconfig and CONFIG_PHY_MVEBU_CP110_COMPHY=m.

Closes: https://lore.kernel.org/r/b71596c7-461b-44b6-89ab-3cfbd492639f@solid-run.com Signed-off-by: Josua Mayer josua@solid-run.com Reviewed-by: Andrew Lunn andrew@lunn.ch Signed-off-by: Gregory CLEMENT gregory.clement@bootlin.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: clk: mvebu: cp110 add CLK_IGNORE_UNUSED to pcie_x10, pcie_x11 & pcie_x4

### 1. COMMIT MESSAGE ANALYSIS

**Subject:** Adding CLK_IGNORE_UNUSED flag to three PCIe clock gates on Marvell CP110 platforms.

**Key problem described:** - CP110 platforms rely on bootloader for PCIe port initialization - TF-A (Trusted Firmware-A) prevents non-U-Boot reconfiguration of PCIe lanes - Many boards lack software control over PCIe card reset - If a PCIe port had an active link at boot and the clock is stopped later, the link fails permanently and cannot be recovered - PCIe controller driver probe may be delayed on large modular kernels, causing the clock framework to disable "unused" clocks before the driver takes ownership

**Important tags:** - **No "Cc: stable@vger.kernel.org"** - maintainer didn't explicitly request backport - **No "Fixes:" tag** - unclear when the issue was introduced - **Reviewed-by: Andrew Lunn** - reputable ARM/networking kernel developer - **Closes:** link to lore.kernel.org bug report - confirms real users hit this

### 2. CODE CHANGE ANALYSIS

The change adds a new `gate_flags()` helper function that returns `CLK_IGNORE_UNUSED` for three specific clock gates: - `CP110_GATE_PCIE_X1_0` (pcie_x10) - `CP110_GATE_PCIE_X1_1` (pcie_x11) - `CP110_GATE_PCIE_X4` (pcie_x4)

This flag is then passed to `init.flags` when registering gate clocks.

**Technical mechanism of the bug:** 1. Boot proceeds with PCIe link established by bootloader 2. Clock framework marks these PCIe clocks as "unused" (no driver claimed them yet) 3. Late in boot, clock framework garbage-collects unused clocks 4. PCIe clocks are disabled, breaking the active link 5. When PCIe driver finally probes (especially in modular configs), link is irrecoverably failed

**What CLK_IGNORE_UNUSED does:** Tells the clock framework to never disable these clocks just because they appear unclaimed. This is the standard mechanism for clocks that must remain active until a driver explicitly takes ownership.

### 3. CLASSIFICATION

**Type:** Hardware workaround / quirk for platform-specific behavior

This falls into the "quirks and workarounds" exception category for stable kernels. It's a workaround for the specific constraints of the Marvell CP110 platform where: - TF-A manages PCIe lane configuration - Clock disable breaks PCIe links irreversibly - Driver load timing varies across kernel configurations

### 4. SCOPE AND RISK ASSESSMENT

**Size:** ~21 lines added, 1 file changed, self-contained

**Risk level:** LOW - Only affects Marvell CP110 platforms - No changes to core clock framework - Worst case: slightly higher power consumption (clocks stay on when could be off) - No chance of breaking other subsystems

**Subsystem:** mvebu clock driver - mature platform-specific driver

### 5. USER IMPACT

**Affected users:** Marvell CP110-based platforms (Armada 7K/8K, SolidRun products, etc.)

**Severity:** HIGH for affected users - PCIe devices completely fail to be detected

**Real-world evidence:** - Bug report on lore.kernel.org linked in commit - Reproducible with "arm64 defconfig and CONFIG_PHY_MVEBU_CP110_COMPHY=m"

### 6. STABILITY INDICATORS

- **Reviewed-by:** Andrew Lunn (highly respected maintainer for this subsystem) - The CP110 clock driver has existed for years - this isn't new code - Change is isolated and uses standard clock framework mechanisms

### 7. DEPENDENCY CHECK

- Self-contained change, no dependencies on other commits - The CP110 clock driver exists in stable trees - No required prerequisite patches

### CONCERNS

1. **No explicit stable tag** - maintainer didn't mark for backport 2. **No Fixes: tag** - we don't know how far back this issue goes 3. **Workaround approach** - CLK_IGNORE_UNUSED is somewhat heavy-handed but appropriate here

### DECISION ANALYSIS

**For backporting:** - Fixes real hardware failure (PCIe not working) on production hardware - Small, surgical, self-contained fix - Very low regression risk (only affects specific ARM platform) - Follows the "hardware quirk" exception pattern for stable - Uses standard clock framework mechanisms - Has review from reputable subsystem maintainer

**Against backporting:** - No Cc: stable from maintainer - Affects relatively niche ARM SoC platform - No indication of when bug was introduced

### Conclusion

This commit fixes a real, user-impacting bug where PCIe devices fail to be detected on Marvell CP110-based platforms. The fix is a standard hardware quirk/workaround pattern - adding CLK_IGNORE_UNUSED to prevent premature clock disabling that breaks active PCIe links. The change is small (~21 lines), isolated to a single platform-specific driver, carries minimal regression risk, and has been reviewed by a reputable kernel maintainer.

While there's no explicit stable tag, this fits the stable criteria for hardware workarounds that fix real user-facing bugs. The worst case (clocks stay on unnecessarily) is far preferable to the current bug (PCIe completely broken).

**YES**

drivers/clk/mvebu/cp110-system-controller.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)

diff --git a/drivers/clk/mvebu/cp110-system-controller.c b/drivers/clk/mvebu/cp110-system-controller.c index 03c59bf221060..b47c869060466 100644 --- a/drivers/clk/mvebu/cp110-system-controller.c +++ b/drivers/clk/mvebu/cp110-system-controller.c @@ -110,6 +110,25 @@ static const char * const gate_base_names[] = { [CP110_GATE_EIP197] = "eip197" };

+static unsigned long gate_flags(const u8 bit_idx) +{ + switch (bit_idx) { + case CP110_GATE_PCIE_X1_0: + case CP110_GATE_PCIE_X1_1: + case CP110_GATE_PCIE_X4: + /* + * If a port had an active link at boot time, stopping + * the clock creates a failed state from which controller + * driver can not recover. + * Prevent stopping this clock till after a driver has taken + * ownership. + */ + return CLK_IGNORE_UNUSED; + default: + return 0; + } +}; + struct cp110_gate_clk { struct clk_hw hw; struct regmap *regmap; @@ -171,6 +190,7 @@ static struct clk_hw *cp110_register_gate(const char *name, init.ops = &cp110_gate_ops; init.parent_names = &parent_name; init.num_parents = 1; + init.flags = gate_flags(bit_idx);

gate->regmap = regmap; gate->bit_idx = bit_idx;

From: Yuezhang Mo Yuezhang.Mo@sony.com

[ Upstream commit 51fc7b4ce10ccab8ea5e4876bcdc42cf5202a0ef ]

The kernel test robot reported that the exFAT remount operation failed. The reason for the failure was that the process's umask is different between mount and remount, causing fs_fmask and fs_dmask are changed.

Potentially, both gid and uid may also be changed. Therefore, when initializing fs_context for remount, inherit these mount options from the options used during mount.

Reported-by: kernel test robot oliver.sang@intel.com Closes: https://lore.kernel.org/oe-lkp/202511251637.81670f5c-lkp@intel.com Signed-off-by: Yuezhang Mo Yuezhang.Mo@sony.com Signed-off-by: Namjae Jeon linkinjeon@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: exfat: fix remount failure in different process environments

### 1. COMMIT MESSAGE ANALYSIS

**Subject**: Contains "fix" keyword indicating a bug fix for remount failures.

**Key details from message**: - Reported by kernel test robot - this is a real, reproducible issue - Root cause: When remounting, the process's umask may differ from the original mount, causing `fs_fmask` and `fs_dmask` to unexpectedly change - The same issue applies to `gid` and `uid` - Has `Closes:` link to the bug report

**Missing tags**: - No `Cc: stable@vger.kernel.org` - No `Fixes:` tag indicating when the bug was introduced

### 2. CODE CHANGE ANALYSIS

**The Bug**: ```c // BEFORE: Always uses current process values sbi->options.fs_uid = current_uid(); sbi->options.fs_gid = current_gid(); sbi->options.fs_fmask = current->fs->umask; sbi->options.fs_dmask = current->fs->umask; ```

When `exfat_init_fs_context()` is called for a remount operation, it was incorrectly initializing uid/gid/fmask/dmask from the **current process** rather than preserving the existing mount options. If the process performing the remount has a different umask (or runs as a different user), the options change unexpectedly, causing remount validation failures.

**The Fix**: ```c // AFTER: Check if this is a remount and inherit existing options if (fc->purpose == FS_CONTEXT_FOR_RECONFIGURE && fc->root) { struct super_block *sb = fc->root->d_sb; struct exfat_mount_options *cur_opts = &EXFAT_SB(sb)->options;

sbi->options.fs_uid = cur_opts->fs_uid; sbi->options.fs_gid = cur_opts->fs_gid; sbi->options.fs_fmask = cur_opts->fs_fmask; sbi->options.fs_dmask = cur_opts->fs_dmask; } else { // Original behavior for initial mount ... } ```

This is the correct behavior - remount should preserve existing mount options unless explicitly overridden by the user.

### 3. CLASSIFICATION

- **Type**: Bug fix (not a feature) - **Category**: Filesystem correctness issue - **Security**: Not a security issue

### 4. SCOPE AND RISK ASSESSMENT

| Metric | Value | |--------|-------| | Lines changed | ~15 (net +11) | | Files touched | 1 (fs/exfat/super.c) | | Complexity | Low - simple conditional logic | | Risk | Low - uses well-established fs_context patterns |

The fix is surgically targeted at `exfat_init_fs_context()` and uses standard fs_context APIs (`fc->purpose`, `fc->root`, `FS_CONTEXT_FOR_RECONFIGURE`) that other filesystems use identically.

### 5. USER IMPACT

- **Affected users**: Anyone using exFAT filesystems who performs remount operations - **Scenario**: Common when system scripts, systemd units, or root user (with different umask) remount a filesystem - **Severity**: Medium - causes remount failures, but not data corruption - **Real-world impact**: Yes - kernel test robot found this in automated testing

### 6. STABILITY INDICATORS

- Signed-off by exFAT maintainer (Namjae Jeon) - Triggered by automated kernel testing - Logic is straightforward and follows established patterns used by other filesystems

### 7. DEPENDENCY CHECK

The fix relies on: - `fc->purpose` and `fc->root` - standard fs_context fields available since the fs_context API conversion - `EXFAT_SB()` macro - existing exFAT infrastructure - `FS_CONTEXT_FOR_RECONFIGURE` - standard kernel constant

No additional dependencies required. The fix applies to any kernel with exFAT's fs_context implementation.

### STABLE KERNEL CRITERIA EVALUATION

| Criterion | Met? | |-----------|------| | Obviously correct | ✅ Yes - straightforward logic | | Fixes real bug | ✅ Yes - reported by kernel test robot | | Small and contained | ✅ Yes - single function, ~15 lines | | No new features | ✅ Yes - corrects existing behavior | | No new APIs | ✅ Yes - uses existing fs_context APIs |

### VERDICT

This commit fixes a genuine bug where exFAT remount operations fail when the remounting process has a different umask than the original mounting process. The fix is:

1. **Small and localized** - modifies one function in one file 2. **Obviously correct** - follows the same pattern other filesystems use for handling remount context initialization 3. **Low risk** - no architectural changes, just proper option inheritance 4. **User-impacting** - remount failures are a real usability issue

While the commit lacks explicit `Cc: stable` and `Fixes:` tags, the nature of the fix (correcting filesystem remount behavior) and its minimal footprint make it appropriate for stable backporting. The risk- benefit ratio strongly favors inclusion.

**YES**

fs/exfat/super.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/fs/exfat/super.c b/fs/exfat/super.c index 74d451f732c73..581754001128b 100644 --- a/fs/exfat/super.c +++ b/fs/exfat/super.c @@ -813,10 +813,21 @@ static int exfat_init_fs_context(struct fs_context *fc) ratelimit_state_init(&sbi->ratelimit, DEFAULT_RATELIMIT_INTERVAL, DEFAULT_RATELIMIT_BURST);

- sbi->options.fs_uid = current_uid(); - sbi->options.fs_gid = current_gid(); - sbi->options.fs_fmask = current->fs->umask; - sbi->options.fs_dmask = current->fs->umask; + if (fc->purpose == FS_CONTEXT_FOR_RECONFIGURE && fc->root) { + struct super_block *sb = fc->root->d_sb; + struct exfat_mount_options *cur_opts = &EXFAT_SB(sb)->options; + + sbi->options.fs_uid = cur_opts->fs_uid; + sbi->options.fs_gid = cur_opts->fs_gid; + sbi->options.fs_fmask = cur_opts->fs_fmask; + sbi->options.fs_dmask = cur_opts->fs_dmask; + } else { + sbi->options.fs_uid = current_uid(); + sbi->options.fs_gid = current_gid(); + sbi->options.fs_fmask = current->fs->umask; + sbi->options.fs_dmask = current->fs->umask; + } + sbi->options.allow_utime = -1; sbi->options.errors = EXFAT_ERRORS_RO; exfat_set_iocharset(&sbi->options, exfat_default_iocharset);

From: Tony Battersby tonyb@cybernetics.com

[ Upstream commit 4f6aaade2a22ac428fa99ed716cf2b87e79c9837 ]

When qla2xxx is loaded with qlini_mode=disabled, ha->flags.disable_msix_handshake is used before it is set, resulting in the wrong interrupt handler being used on certain HBAs (qla2xxx_msix_rsp_q_hs() is used when qla2xxx_msix_rsp_q() should be used). The only difference between these two interrupt handlers is that the _hs() version writes to a register to clear the "RISC" interrupt, whereas the other version does not. So this bug results in the RISC interrupt being cleared when it should not be. This occasionally causes a different interrupt handler qla24xx_msix_default() for a different vector to see ((stat & HSRX_RISC_INT) == 0) and ignore its interrupt, which then causes problems like:

qla2xxx [0000:02:00.0]-d04c:6: MBX Command timeout for cmd 20, iocontrol=8 jiffies=1090c0300 mb[0-3]=[0x4000 0x0 0x40 0xda] mb7 0x500 host_status 0x40000010 hccr 0x3f00 qla2xxx [0000:02:00.0]-101e:6: Mailbox cmd timeout occurred, cmd=0x20, mb[0]=0x20. Scheduling ISP abort (the cmd varies; sometimes it is 0x20, 0x22, 0x54, 0x5a, 0x5d, or 0x6a)

This problem can be reproduced with a 16 or 32 Gbps HBA by loading qla2xxx with qlini_mode=disabled and running a high IOPS test while triggering frequent RSCN database change events.

While analyzing the problem I discovered that even with disable_msix_handshake forced to 0, it is not necessary to clear the RISC interrupt from qla2xxx_msix_rsp_q_hs() (more below). So just completely remove qla2xxx_msix_rsp_q_hs() and the logic for selecting it, which also fixes the bug with qlini_mode=disabled.

The test below describes the justification for not needing qla2xxx_msix_rsp_q_hs():

Force disable_msix_handshake to 0: qla24xx_config_rings(): if (0 && (ha->fw_attributes & BIT_6) && (IS_MSIX_NACK_CAPABLE(ha)) && (ha->flags.msix_enabled)) {

In qla24xx_msix_rsp_q() and qla2xxx_msix_rsp_q_hs(), check: (rd_reg_dword(&reg->host_status) & HSRX_RISC_INT)

Count the number of calls to each function with HSRX_RISC_INT set and the number with HSRX_RISC_INT not set while performing some I/O.

If qla2xxx_msix_rsp_q_hs() clears the RISC interrupt (original code): qla24xx_msix_rsp_q: 50% of calls have HSRX_RISC_INT set qla2xxx_msix_rsp_q_hs: 5% of calls have HSRX_RISC_INT set (# of qla2xxx_msix_rsp_q_hs interrupts) = (# of qla24xx_msix_rsp_q interrupts) * 3

If qla2xxx_msix_rsp_q_hs() does not clear the RISC interrupt (patched code): qla24xx_msix_rsp_q: 100% of calls have HSRX_RISC_INT set qla2xxx_msix_rsp_q_hs: 9% of calls have HSRX_RISC_INT set (# of qla2xxx_msix_rsp_q_hs interrupts) = (# of qla24xx_msix_rsp_q interrupts) * 3

In the case of the original code, qla24xx_msix_rsp_q() was seeing HSRX_RISC_INT set only 50% of the time because qla2xxx_msix_rsp_q_hs() was clearing it when it shouldn't have been. In the patched code, qla24xx_msix_rsp_q() sees HSRX_RISC_INT set 100% of the time, which makes sense if that interrupt handler needs to clear the RISC interrupt (which it does). qla2xxx_msix_rsp_q_hs() sees HSRX_RISC_INT only 9% of the time, which is just overlap from the other interrupt during the high IOPS test.

Tested with SCST on: QLE2742 FW:v9.08.02 (32 Gbps 2-port) QLE2694L FW:v9.10.11 (16 Gbps 4-port) QLE2694L FW:v9.08.02 (16 Gbps 4-port) QLE2672 FW:v8.07.12 (16 Gbps 2-port) both initiator and target mode

Signed-off-by: Tony Battersby tonyb@cybernetics.com Link: https://patch.msgid.link/56d378eb-14ad-49c7-bae9-c649b6c7691e@cybernetics.co... 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:

## Analysis of qla2xxx Lost Interrupts Fix

### 1. COMMIT MESSAGE ANALYSIS

**Subject**: "scsi: qla2xxx: Fix lost interrupts with qlini_mode=disabled"

Key findings: - Contains "Fix" keyword indicating a bug fix - No `Cc: stable@vger.kernel.org` tag present - No `Fixes:` tag present - Describes a clear user-visible problem: mailbox command timeouts and ISP aborts - Symptoms documented include: ``` MBX Command timeout for cmd 20... Scheduling ISP abort ```

### 2. CODE CHANGE ANALYSIS

**Root Cause**: `ha->flags.disable_msix_handshake` is accessed before it's set during initialization. This causes incorrect interrupt handler selection: - `qla2xxx_msix_rsp_q_hs()` is erroneously used when `qla2xxx_msix_rsp_q()` should be used - The `_hs` handler clears the RISC interrupt when it shouldn't - This causes `qla24xx_msix_default()` to see `(stat & HSRX_RISC_INT) == 0` and ignore its interrupt

**The Fix**: 1. Removes the problematic `qla2xxx_msix_rsp_q_hs()` handler entirely 2. Removes `QLA_MSIX_QPAIR_MULTIQ_RSP_Q_HS` definition 3. Simplifies `qla25xx_request_irq()` by removing `vector_type` parameter 4. Always uses the correct `qla2xxx_msix_rsp_q` handler

**Why This Works**: The author's testing shows that the RISC interrupt clearing in `_hs` was never necessary - removing it actually improves correctness (100% of calls see HSRX_RISC_INT set vs 50% previously).

### 3. CLASSIFICATION

- **Bug fix**: Yes - fixes lost interrupts causing command timeouts - **Feature addition**: No - actually *removes* code - **Security fix**: No - **Hardware affected**: QLogic FC HBAs (16/32 Gbps) in enterprise environments

### 4. SCOPE AND RISK ASSESSMENT

| Metric | Assessment | |--------|------------| | Files changed | 4 (all qla2xxx driver) | | Net lines | Negative (code removal) | | Subsystem | SCSI/qla2xxx - mature, enterprise driver | | Risk level | LOW - removes problematic code path |

The fix is self-contained and simplifies rather than complicates the code.

### 5. USER IMPACT

**Affected users**: - QLogic FC HBA users with `qlini_mode=disabled` (target mode) - High IOPS environments with frequent RSCN events - Enterprise storage deployments using SCST

**Severity**: HIGH - Command timeouts cause I/O disruptions - ISP aborts can trigger path failovers - Production storage environments severely impacted

### 6. STABILITY INDICATORS

**Testing documented**: - QLE2742 FW:v9.08.02 (32 Gbps) - QLE2694L FW:v9.10.11 and v9.08.02 (16 Gbps) - QLE2672 FW:v8.07.12 (16 Gbps) - Both initiator and target modes tested

**Sign-offs**: Tony Battersby (author), Martin K. Petersen (SCSI maintainer)

### 7. DEPENDENCY CHECK

- No dependencies on other commits - Self-contained within qla2xxx driver - The affected code (multi-queue support) exists in stable trees

### 8. CONCERNS

1. **No explicit stable tags**: Maintainer didn't request backport explicitly 2. **No Fixes: tag**: Unknown exactly when bug was introduced 3. **Configuration-specific**: Only affects `qlini_mode=disabled` mode 4. **Removes entire handler**: Could theoretically affect unknown edge cases

### FINAL ASSESSMENT

**Arguments FOR backport**: - Fixes real, user-visible bug causing command timeouts and ISP aborts - Affects enterprise FC storage deployments in target mode - Low risk - removes problematic code rather than adding new code - Extensively tested on multiple HBA models - SCSI maintainer approved - Self-contained fix with no dependencies

**Arguments AGAINST backport**: - No explicit stable request from maintainers - Touches multiple functions (though all removals) - Affects specific configuration (target mode)

The fix addresses a significant reliability issue in enterprise storage environments. While lacking explicit stable tags, the nature of the fix (removing buggy code, not adding features), the thorough testing, and the severity of the symptoms (command timeouts, ISP aborts in production) make this appropriate for stable backport. The code removal approach minimizes regression risk.

**YES**

drivers/scsi/qla2xxx/qla_def.h | 1 - drivers/scsi/qla2xxx/qla_gbl.h | 2 +- drivers/scsi/qla2xxx/qla_isr.c | 32 +++----------------------------- drivers/scsi/qla2xxx/qla_mid.c | 4 +--- 4 files changed, 5 insertions(+), 34 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h index cb95b7b12051d..b3265952c4bed 100644 --- a/drivers/scsi/qla2xxx/qla_def.h +++ b/drivers/scsi/qla2xxx/qla_def.h @@ -3503,7 +3503,6 @@ struct isp_operations { #define QLA_MSIX_RSP_Q 0x01 #define QLA_ATIO_VECTOR 0x02 #define QLA_MSIX_QPAIR_MULTIQ_RSP_Q 0x03 -#define QLA_MSIX_QPAIR_MULTIQ_RSP_Q_HS 0x04

#define QLA_MIDX_DEFAULT 0 #define QLA_MIDX_RSP_Q 1 diff --git a/drivers/scsi/qla2xxx/qla_gbl.h b/drivers/scsi/qla2xxx/qla_gbl.h index 145defc420f27..55d531c19e6b2 100644 --- a/drivers/scsi/qla2xxx/qla_gbl.h +++ b/drivers/scsi/qla2xxx/qla_gbl.h @@ -766,7 +766,7 @@ extern int qla2x00_dfs_remove(scsi_qla_host_t *);

/* Globa function prototypes for multi-q */ extern int qla25xx_request_irq(struct qla_hw_data *, struct qla_qpair *, - struct qla_msix_entry *, int); + struct qla_msix_entry *); extern int qla25xx_init_req_que(struct scsi_qla_host *, struct req_que *); extern int qla25xx_init_rsp_que(struct scsi_qla_host *, struct rsp_que *); extern int qla25xx_create_req_que(struct qla_hw_data *, uint16_t, uint8_t, diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c index c4c6b5c6658c0..a3971afc2dd1e 100644 --- a/drivers/scsi/qla2xxx/qla_isr.c +++ b/drivers/scsi/qla2xxx/qla_isr.c @@ -4467,32 +4467,6 @@ qla2xxx_msix_rsp_q(int irq, void *dev_id) return IRQ_HANDLED; }

-irqreturn_t -qla2xxx_msix_rsp_q_hs(int irq, void *dev_id) -{ - struct qla_hw_data *ha; - struct qla_qpair *qpair; - struct device_reg_24xx __iomem *reg; - unsigned long flags; - - qpair = dev_id; - if (!qpair) { - ql_log(ql_log_info, NULL, 0x505b, - "%s: NULL response queue pointer.\n", __func__); - return IRQ_NONE; - } - ha = qpair->hw; - - reg = &ha->iobase->isp24; - spin_lock_irqsave(&ha->hardware_lock, flags); - wrt_reg_dword(&reg->hccr, HCCRX_CLR_RISC_INT); - spin_unlock_irqrestore(&ha->hardware_lock, flags); - - queue_work(ha->wq, &qpair->q_work); - - return IRQ_HANDLED; -} - /* Interrupt handling helpers. */

struct qla_init_msix_entry { @@ -4505,7 +4479,6 @@ static const struct qla_init_msix_entry msix_entries[] = { { "rsp_q", qla24xx_msix_rsp_q }, { "atio_q", qla83xx_msix_atio_q }, { "qpair_multiq", qla2xxx_msix_rsp_q }, - { "qpair_multiq_hs", qla2xxx_msix_rsp_q_hs }, };

static const struct qla_init_msix_entry qla82xx_msix_entries[] = { @@ -4792,9 +4765,10 @@ qla2x00_free_irqs(scsi_qla_host_t *vha) }

int qla25xx_request_irq(struct qla_hw_data *ha, struct qla_qpair *qpair, - struct qla_msix_entry *msix, int vector_type) + struct qla_msix_entry *msix) { - const struct qla_init_msix_entry *intr = &msix_entries[vector_type]; + const struct qla_init_msix_entry *intr = + &msix_entries[QLA_MSIX_QPAIR_MULTIQ_RSP_Q]; scsi_qla_host_t *vha = pci_get_drvdata(ha->pdev); int ret;

diff --git a/drivers/scsi/qla2xxx/qla_mid.c b/drivers/scsi/qla2xxx/qla_mid.c index 8b71ac0b1d999..0abc47e72e0bf 100644 --- a/drivers/scsi/qla2xxx/qla_mid.c +++ b/drivers/scsi/qla2xxx/qla_mid.c @@ -899,9 +899,7 @@ qla25xx_create_rsp_que(struct qla_hw_data *ha, uint16_t options, rsp->options, rsp->id, rsp->rsp_q_in, rsp->rsp_q_out);

- ret = qla25xx_request_irq(ha, qpair, qpair->msix, - ha->flags.disable_msix_handshake ? - QLA_MSIX_QPAIR_MULTIQ_RSP_Q : QLA_MSIX_QPAIR_MULTIQ_RSP_Q_HS); + ret = qla25xx_request_irq(ha, qpair, qpair->msix); if (ret) goto que_failed;

From: Johannes Berg johannes.berg@intel.com

[ Upstream commit 7b5d4416964c07c902163822a30a622111172b01 ]

This is currently done in uml_finishsetup(), but e.g. with KCOV enabled we'll crash because some init code can call into e.g. memparse(), which has coverage annotations, and then the checks in check_kcov_mode() crash because current is NULL.

Simply initialize the cpu_tasks[] array statically, which fixes the crash. For the later SMP work, it seems to have not really caused any problems yet, but initialize all of the entries anyway.

Link: https://patch.msgid.link/20250924113214.c76cd74d0583.I974f691ebb1a2b47915bd2... Signed-off-by: Johannes Berg johannes.berg@intel.com Signed-off-by: Sasha Levin sashal@kernel.org ---

LLM Generated explanations, may be completely bogus:

## Analysis Summary

### Bug Mechanism

This commit fixes a **boot crash** in User Mode Linux (UML) when KCOV (kernel code coverage) is enabled:

1. **Root cause**: In UML, `current` is defined as `cpu_tasks[0]` (see `arch/um/include/asm/current.h:15`) 2. **Problem**: `cpu_tasks[]` was uninitialized (NULL) until `uml_finishsetup()` was called late in boot 3. **Trigger**: With KCOV enabled, early init code calls coverage- annotated functions like `memparse()` 4. **Crash path**: KCOV's `__sanitizer_cov_trace_pc` → `check_kcov_mode(current)` → dereferences NULL `current` → crash

### The Fix

The fix is elegantly simple: - **Before**: `struct task_struct *cpu_tasks[NR_CPUS];` (zero- initialized, i.e., NULL) - **After**: `struct task_struct *cpu_tasks[NR_CPUS] = { [0 ... NR_CPUS - 1] = &init_task };`

This ensures `current` is valid (`&init_task`) from the very start of kernel execution. The runtime initialization in `uml_finishsetup()` is removed since it's now redundant.

### Stable Criteria Assessment

| Criteria | Assessment | |----------|------------| | Fixes a real bug? | **YES** - Boot crash with KCOV enabled | | Obviously correct? | **YES** - Same value (`&init_task`), just initialized earlier | | Small and contained? | **YES** - 2 files, +3/-3 lines, net -1 | | No new features? | **YES** - Pure bug fix | | Low regression risk? | **YES** - Identical initialization, just at compile time | | Self-contained? | **YES** - No dependencies on other patches |

### Risk Assessment

- **Risk**: Very low. The initialization value is exactly what was done before in `uml_finishsetup()`, just done statically at compile time instead of at runtime. - **Scope**: Limited to UML architecture only - **Impact**: Fixes complete boot failure for UML+KCOV users

### Concerns

- No explicit `Cc: stable@vger.kernel.org` tag - No `Fixes:` tag to identify when bug was introduced - Affects only UML users (niche architecture, but important for kernel testing/development)

### Conclusion

This is a textbook stable backport candidate: - Fixes a real, reproducible crash (not theoretical) - The fix is minimal, surgical, and obviously correct - Zero risk of introducing regressions since the same value is used, just initialized earlier - The infrastructure (`init_task`, `cpu_tasks[]`) has existed in stable trees for years

The lack of explicit stable tags appears to be an oversight. The fix is appropriate for any stable tree that has both UML support and KCOV support.

**YES**

arch/um/kernel/process.c | 4 +++- arch/um/kernel/um_arch.c | 2 -- 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/um/kernel/process.c b/arch/um/kernel/process.c index 9c9c66dc45f05..13d461712c997 100644 --- a/arch/um/kernel/process.c +++ b/arch/um/kernel/process.c @@ -43,7 +43,9 @@ * cares about its entry, so it's OK if another processor is modifying its * entry. */ -struct task_struct *cpu_tasks[NR_CPUS]; +struct task_struct *cpu_tasks[NR_CPUS] = { + [0 ... NR_CPUS - 1] = &init_task, +}; EXPORT_SYMBOL(cpu_tasks);

void free_stack(unsigned long stack, int order) diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c index cfbbbf8500c34..ed2f67848a50e 100644 --- a/arch/um/kernel/um_arch.c +++ b/arch/um/kernel/um_arch.c @@ -239,8 +239,6 @@ static struct notifier_block panic_exit_notifier = {

void uml_finishsetup(void) { - cpu_tasks[0] = &init_task; - atomic_notifier_chain_register(&panic_notifier_list, &panic_exit_notifier);

From: Justin Tee justin.tee@broadcom.com

[ Upstream commit 07caedc6a3887938813727beafea40f07c497705 ]

It's possible for an unstable link to repeatedly bounce allowing a FLOGI retry, but then bounce again forcing an abort of the FLOGI. Ensure that the initial reference count on the FLOGI ndlp is restored in this faulty link scenario.

Signed-off-by: Justin Tee justin.tee@broadcom.com Link: https://patch.msgid.link/20251106224639.139176-8-justintee8345@gmail.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:

Looking at this commit, I need to analyze it thoroughly to determine if it's suitable for stable backporting.

## Commit Analysis

### 1. Problem Being Fixed

This commit fixes a **reference counting bug** in the lpfc (Broadcom Fibre Channel) driver. The issue occurs when:

1. A FLOGI (Fabric Login) is issued on an unstable link 2. The link bounces, causing the FLOGI to abort 3. The ndlp (node list pointer) gets marked `NLP_DROPPED` and its reference count is decremented via `lpfc_nlp_put()` 4. The link comes back and lpfc tries to reuse the same ndlp for a new FLOGI retry 5. The ndlp is still marked `NLP_DROPPED` with a decremented refcount, causing reference count imbalances

This can lead to **use-after-free** or **double-free** conditions - serious kernel stability and security issues.

### 2. Code Changes Analysis

The fix is surgical and well-designed:

**In `lpfc_issue_els_flogi()`:** - Adds a check: if ndlp is marked `NLP_DROPPED`, clear the flag and restore the reference count with `lpfc_nlp_get()` - This is the core fix - properly restoring state when retrying with a previously-dropped ndlp

**In `lpfc_cmpl_els_flogi()`:** - Before calling `lpfc_nlp_put()`, now checks if `NLP_DROPPED` is already set - Sets `NLP_DROPPED` atomically before decrementing to prevent double- decrement

**In `lpfc_dev_loss_tmo_handler()`:** - Uses `test_and_set_bit(NLP_DROPPED, ...)` to atomically check and set, preventing races

**In `lpfc_check_nlp_post_devloss()`:** - Clears `NLP_DROPPED` when restoring the ndlp reference

### 3. Scope and Risk Assessment

- **Files changed:** 2 files in lpfc driver only - **Lines changed:** ~50 lines of code - **Scope:** Limited to lpfc FLOGI handling and devloss timeout paths - **Risk:** MEDIUM - Reference counting changes require care, but these use proper atomic operations (`test_and_set_bit`, `test_and_clear_bit`)

### 4. Stable Criteria Evaluation

**Meets stable criteria:** - ✅ Fixes a real bug (reference count corruption causing potential use- after-free) - ✅ Small and contained to specific driver (lpfc) - ✅ No new features added - ✅ Clear mechanism: adds proper NLP_DROPPED flag tracking to prevent refcount imbalance - ✅ Affects real-world scenarios: unstable FC links occur in enterprise environments

**Concerns:** - ❌ No "Fixes:" tag indicating when bug was introduced - ❌ No "Cc: stable@vger.kernel.org" tag - The `NLP_DROPPED` flag usage appears to exist in older kernels already

### 5. User Impact

- **Who is affected:** Users with Broadcom lpfc Fibre Channel HBAs in enterprise storage environments - **Severity:** HIGH - Reference count bugs can cause kernel crashes, data corruption, or security vulnerabilities - **Likelihood:** MODERATE - Requires unstable FC link conditions, but these occur in real deployments

### 6. Backport Feasibility

The changes use standard kernel primitives (`test_and_set_bit`, `test_and_clear_bit`). The `NLP_DROPPED` flag and the functions being modified (`lpfc_nlp_put`, `lpfc_nlp_get`, `lpfc_check_nlp_post_devloss`) appear to exist in stable kernels. The patch should apply cleanly or with minor adjustments.

## Conclusion

This is a legitimate bug fix for a reference counting issue that can cause serious problems (use-after-free, crashes) in enterprise Fibre Channel environments. The fix is well-designed with proper atomic operations and is contained to the lpfc driver. While there's no explicit stable tag, the nature of the bug (reference counting corruption in a widely-used enterprise driver) makes it appropriate for stable backporting.

The fix is small, surgical, and addresses a real stability/potential security issue. Enterprise users with lpfc HBAs who experience link instability would benefit from this fix.

**YES**

drivers/scsi/lpfc/lpfc_els.c | 36 +++++++++++++++++++++++++------- drivers/scsi/lpfc/lpfc_hbadisc.c | 4 +++- 2 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c index b71db7d7d747d..c08237f04bce2 100644 --- a/drivers/scsi/lpfc/lpfc_els.c +++ b/drivers/scsi/lpfc/lpfc_els.c @@ -934,10 +934,15 @@ lpfc_cmpl_els_flogi(struct lpfc_hba *phba, struct lpfc_iocbq *cmdiocb, /* Check to see if link went down during discovery */ if (lpfc_els_chk_latt(vport)) { /* One additional decrement on node reference count to - * trigger the release of the node + * trigger the release of the node. Make sure the ndlp + * is marked NLP_DROPPED. */ - if (!(ndlp->fc4_xpt_flags & SCSI_XPT_REGD)) + if (!test_bit(NLP_IN_DEV_LOSS, &ndlp->nlp_flag) && + !test_bit(NLP_DROPPED, &ndlp->nlp_flag) && + !(ndlp->fc4_xpt_flags & SCSI_XPT_REGD)) { + set_bit(NLP_DROPPED, &ndlp->nlp_flag); lpfc_nlp_put(ndlp); + } goto out; }

@@ -995,9 +1000,10 @@ lpfc_cmpl_els_flogi(struct lpfc_hba *phba, struct lpfc_iocbq *cmdiocb, IOERR_LOOP_OPEN_FAILURE))) lpfc_vlog_msg(vport, KERN_WARNING, LOG_ELS, "2858 FLOGI Status:x%x/x%x TMO" - ":x%x Data x%lx x%x\n", + ":x%x Data x%lx x%x x%lx x%x\n", ulp_status, ulp_word4, tmo, - phba->hba_flag, phba->fcf.fcf_flag); + phba->hba_flag, phba->fcf.fcf_flag, + ndlp->nlp_flag, ndlp->fc4_xpt_flags);

/* Check for retry */ if (lpfc_els_retry(phba, cmdiocb, rspiocb)) { @@ -1015,14 +1021,17 @@ lpfc_cmpl_els_flogi(struct lpfc_hba *phba, struct lpfc_iocbq *cmdiocb, * reference to trigger node release. */ if (!test_bit(NLP_IN_DEV_LOSS, &ndlp->nlp_flag) && - !(ndlp->fc4_xpt_flags & SCSI_XPT_REGD)) + !test_bit(NLP_DROPPED, &ndlp->nlp_flag) && + !(ndlp->fc4_xpt_flags & SCSI_XPT_REGD)) { + set_bit(NLP_DROPPED, &ndlp->nlp_flag); lpfc_nlp_put(ndlp); + }

lpfc_printf_vlog(vport, KERN_WARNING, LOG_ELS, "0150 FLOGI Status:x%x/x%x " - "xri x%x TMO:x%x refcnt %d\n", + "xri x%x iotag x%x TMO:x%x refcnt %d\n", ulp_status, ulp_word4, cmdiocb->sli4_xritag, - tmo, kref_read(&ndlp->kref)); + cmdiocb->iotag, tmo, kref_read(&ndlp->kref));

/* If this is not a loop open failure, bail out */ if (!(ulp_status == IOSTAT_LOCAL_REJECT && @@ -1279,6 +1288,19 @@ lpfc_issue_els_flogi(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp, uint32_t tmo, did; int rc;

+ /* It's possible for lpfc to reissue a FLOGI on an ndlp that is marked + * NLP_DROPPED. This happens when the FLOGI completed with the XB bit + * set causing lpfc to reference the ndlp until the XRI_ABORTED CQE is + * issued. The time window for the XRI_ABORTED CQE can be as much as + * 2*2*RA_TOV allowing for ndlp reuse of this type when the link is + * cycling quickly. When true, restore the initial reference and remove + * the NLP_DROPPED flag as lpfc is retrying. + */ + if (test_and_clear_bit(NLP_DROPPED, &ndlp->nlp_flag)) { + if (!lpfc_nlp_get(ndlp)) + return 1; + } + cmdsize = (sizeof(uint32_t) + sizeof(struct serv_parm)); elsiocb = lpfc_prep_els_iocb(vport, 1, cmdsize, retry, ndlp, ndlp->nlp_DID, ELS_CMD_FLOGI); diff --git a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c index 43d246c5c049c..717ae56c8e4bd 100644 --- a/drivers/scsi/lpfc/lpfc_hbadisc.c +++ b/drivers/scsi/lpfc/lpfc_hbadisc.c @@ -424,6 +424,7 @@ lpfc_check_nlp_post_devloss(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp) { if (test_and_clear_bit(NLP_IN_RECOV_POST_DEV_LOSS, &ndlp->save_flags)) { + clear_bit(NLP_DROPPED, &ndlp->nlp_flag); lpfc_nlp_get(ndlp); lpfc_printf_vlog(vport, KERN_INFO, LOG_DISCOVERY | LOG_NODE, "8438 Devloss timeout reversed on DID x%x " @@ -566,7 +567,8 @@ lpfc_dev_loss_tmo_handler(struct lpfc_nodelist *ndlp) return fcf_inuse; }

- lpfc_nlp_put(ndlp); + if (!test_and_set_bit(NLP_DROPPED, &ndlp->nlp_flag)) + lpfc_nlp_put(ndlp); return fcf_inuse; }