* [PATCH AUTOSEL 6.17-5.15] tracing/tools: Fix incorrcet short option in usage text for --threads
2025-11-10 19:57 [PATCH AUTOSEL 6.17-6.12] drm/amdgpu: fix gpu page fault after hibernation on PF passthrough Sasha Levin
@ 2025-11-10 19:57 ` Sasha Levin
2025-11-10 19:57 ` [PATCH AUTOSEL 6.17-5.4] net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Sasha Levin
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2025-11-10 19:57 UTC (permalink / raw)
To: patches, stable
Cc: Zhang Chujun, Steven Rostedt (Google), Sasha Levin,
alexandre.f.demers, alexander.deucher
From: Zhang Chujun <zhangchujun@cmss.chinamobile.com>
[ Upstream commit 53afec2c8fb2a562222948cb1c2aac48598578c9 ]
The help message incorrectly listed '-t' as the short option for
--threads, but the actual getopt_long configuration uses '-e'.
This mismatch can confuse users and lead to incorrect command-line
usage. This patch updates the usage string to correctly show:
"-e, --threads NRTHR"
to match the implementation.
Note: checkpatch.pl reports a false-positive spelling warning on
'Run', which is intentional.
Link: https://patch.msgid.link/20251106031040.1869-1-zhangchujun@cmss.chinamobile.com
Signed-off-by: Zhang Chujun <zhangchujun@cmss.chinamobile.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.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 kernel
repository, here is my assessment:
## Backport Decision: YES
## Detailed Analysis
### 1. Code Changes Examined
The commit changes a single line in the help text of
`tools/tracing/latency/latency-collector.c`:
- **Line 1728**: Changed from `"-t, --threads NRTHR\t..."` to `"-e,
--threads NRTHR\t..."`
### 2. Tools Used for Analysis
Since this is a documentation-only change in a user-space tool (not
kernel code), I used basic repository analysis tools rather than
semantic code analysis tools:
- **Read tool**: Examined the usage text section and surrounding code
context
- **Grep tool**: Searched for and verified:
- The `getopt_long()` configuration (line 1863): confirmed `"e:"` is
in the option string
- The `long_options[]` array (line 1843): confirmed `{ "threads",
required_argument, 0, 'e' }`
- The case handlers: confirmed `case 'e':` handles the threads option
(line 1927)
- Verified `case 't':` is used for the tracer option (line 1873), not
threads
- **Git history**: Reviewed recent commits to understand the file's
maintenance status
### 3. Findings Summary
**Bug Verification:**
- The long_options array at line 1843 explicitly maps `--threads` to
short option `'e'`
- The short option `'t'` is correctly mapped to `--tracer` at line 1832
- The help text incorrectly showed `-t` for `--threads`, creating a
direct conflict with `-t` for `--tracer`
- This would cause user confusion if someone tried to use `-t` expecting
threads behavior but got tracer behavior instead
**Impact Assessment:**
- **Scope**: User-space tool only (tools/tracing/latency/)
- **Risk**: Zero - only a string literal in help text changes
- **Severity**: Low - documentation bug, not functional
- **User Benefit**: Prevents confusion about command-line options
### 4. Reasoning for Backport
This commit should be backported because:
1. **Fixes a Real Bug**: While only documentation, incorrect help text
is a genuine bug that misleads users about the tool's interface
2. **Zero Risk of Regression**: The change is confined to a string
literal in the usage text - there is absolutely no way this can break
anything or cause regressions
3. **Meets Stable Tree Criteria**:
- ✅ Obviously correct (verified against actual implementation)
- ✅ Small and contained (one line)
- ✅ Fixes a user-visible issue
- ✅ Safe to backport
4. **Improves User Experience**: Users on stable kernels who use this
latency collector tool will have correct documentation, reducing
support burden and confusion
5. **Trivial to Backport**: Single line change with no dependencies
6. **Low Priority but Still Valid**: While this is low severity compared
to kernel bugs, it perfectly fits the stable tree philosophy of
including safe, helpful fixes that improve the user experience
without any downside
The fact that it's in the `tools/` directory rather than kernel proper
doesn't disqualify it - documentation correctness matters for all
components distributed with the kernel.
tools/tracing/latency/latency-collector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/tracing/latency/latency-collector.c b/tools/tracing/latency/latency-collector.c
index cf263fe9deaf4..ef97916e3873a 100644
--- a/tools/tracing/latency/latency-collector.c
+++ b/tools/tracing/latency/latency-collector.c
@@ -1725,7 +1725,7 @@ static void show_usage(void)
"-n, --notrace\t\tIf latency is detected, do not print out the content of\n"
"\t\t\tthe trace file to standard output\n\n"
-"-t, --threads NRTHR\tRun NRTHR threads for printing. Default is %d.\n\n"
+"-e, --threads NRTHR\tRun NRTHR threads for printing. Default is %d.\n\n"
"-r, --random\t\tArbitrarily sleep a certain amount of time, default\n"
"\t\t\t%ld ms, before reading the trace file. The\n"
--
2.51.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH AUTOSEL 6.17-5.4] net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error
2025-11-10 19:57 [PATCH AUTOSEL 6.17-6.12] drm/amdgpu: fix gpu page fault after hibernation on PF passthrough Sasha Levin
2025-11-10 19:57 ` [PATCH AUTOSEL 6.17-5.15] tracing/tools: Fix incorrcet short option in usage text for --threads Sasha Levin
@ 2025-11-10 19:57 ` Sasha Levin
2025-11-10 19:57 ` [PATCH AUTOSEL 6.17] scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) Sasha Levin
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2025-11-10 19:57 UTC (permalink / raw)
To: patches, stable
Cc: Nishanth Menon, Simon Horman, Jacob Keller, Jakub Kicinski,
Sasha Levin, alexandre.f.demers, alexander.deucher, linux-kernel,
linux-arm-kernel
From: Nishanth Menon <nm@ti.com>
[ Upstream commit 90a88306eb874fe4bbdd860e6c9787f5bbc588b5 ]
Make knav_dma_open_channel consistently return NULL on error instead
of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h
returns NULL when the driver is disabled, but the driver
implementation does not even return NULL or ERR_PTR on failure,
causing inconsistency in the users. This results in a crash in
netcp_free_navigator_resources as followed (trimmed):
Unhandled fault: alignment exception (0x221) at 0xfffffff2
[fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000
Internal error: : 221 [#1] SMP ARM
Modules linked in:
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE
Hardware name: Keystone
PC is at knav_dma_close_channel+0x30/0x19c
LR is at netcp_free_navigator_resources+0x2c/0x28c
[... TRIM...]
Call trace:
knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c
netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c
netcp_ndo_open from __dev_open+0x114/0x29c
__dev_open from __dev_change_flags+0x190/0x208
__dev_change_flags from netif_change_flags+0x1c/0x58
netif_change_flags from dev_change_flags+0x38/0xa0
dev_change_flags from ip_auto_config+0x2c4/0x11f0
ip_auto_config from do_one_initcall+0x58/0x200
do_one_initcall from kernel_init_freeable+0x1cc/0x238
kernel_init_freeable from kernel_init+0x1c/0x12c
kernel_init from ret_from_fork+0x14/0x38
[... TRIM...]
Standardize the error handling by making the function return NULL on
all error conditions. The API is used in just the netcp_core.c so the
impact is limited.
Note, this change, in effect reverts commit 5b6cb43b4d62 ("net:
ethernet: ti: netcp_core: return error while dma channel open issue"),
but provides a less error prone implementation.
Suggested-by: Simon Horman <horms@kernel.org>
Suggested-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20251103162811.3730055-1-nm@ti.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Based on my comprehensive analysis using semantic code analysis tools
and kernel repository examination, here is my determination:
## **YES** - This commit SHOULD be backported to stable kernel trees
---
## Analysis Summary
### Semantic Analysis Tools Used:
1. **mcp__semcode__find_function** - Located all affected functions
2. **mcp__semcode__find_callers** - Identified call sites and impact
scope
3. **mcp__semcode__find_callchain** - Traced execution paths from user-
space
4. **Read** - Examined header file and code structure
5. **Grep** - Verified net_device_ops assignment
6. **git log/show** - Investigated bug history and kernel version
presence
### Key Findings:
#### 1. **User-Space Triggerable Crash** (CRITICAL)
- **Impact**: The bug causes a kernel crash (alignment exception at
0xfffffff2) when opening a network interface
- **Trigger path**: User command (`ifconfig eth0 up` or `ip link set
eth0 up`) → `__dev_open()` → `netcp_ndo_open()`
(drivers/net/ethernet/ti/netcp_core.c:1942) →
`netcp_setup_navigator_resources()` → `knav_dma_open_channel()`
- **Call graph analysis** shows `netcp_ndo_open` is assigned to
`.ndo_open` in `netcp_netdev_ops` structure, making it directly user-
triggerable
#### 2. **Root Cause Analysis**
The crash occurs due to inconsistent error handling:
- **Header stub** (include/linux/soc/ti/knav_dma.h:168): Returns `NULL`
when driver disabled
- **Driver implementation** (drivers/soc/ti/knav_dma.c:407-487): Returns
`(void *)-EINVAL` (ERR_PTR) on errors
- **Callers** check `IS_ERR()` after calling `knav_dma_open_channel()`
- **Cleanup code** in `netcp_free_navigator_resources()` (line 1548)
only checks `if (netcp->rx_channel)` before calling
`knav_dma_close_channel()`
- When `rx_channel` contains `-EINVAL` (0xfffffff2), it's non-NULL, so
the check passes
- `knav_dma_close_channel()` attempts to dereference this invalid
pointer → alignment exception crash
#### 3. **Impact Scope** (from mcp__semcode__find_callers)
- **Limited scope**: Only 2 callers of `knav_dma_open_channel()`:
- `netcp_setup_navigator_resources()`
(drivers/net/ethernet/ti/netcp_core.c:1582)
- `netcp_txpipe_open()` (drivers/net/ethernet/ti/netcp_core.c:1326)
- **Affected hardware**: TI Keystone SoC users with NetCP driver
- **Files changed**: Only 2 files, both in the same subsystem
#### 4. **Bug Longevity**
- **Introduced**: v4.12 (2017) by commit 5b6cb43b4d625
- **Duration**: ~7-8 years of existence
- **Fixed in**: v6.18-rc5 (November 2024)
- Verified the buggy pattern exists in v6.6 LTS kernel
#### 5. **Change Characteristics**
- **Type**: Pure bug fix (crash fix)
- **Size**: Small and contained
(drivers/net/ethernet/ti/netcp_core.c:1326-1366
netcp_core.c:1582-1694, drivers/soc/ti/knav_dma.c:407-487)
- **Semantic changes** (from code inspection):
- Standardizes return value from ERR_PTR to NULL on all error paths
- Updates callers from `IS_ERR()` checks to simple NULL checks
- Updates cleanup from `IS_ERR_OR_NULL()` to simple NULL checks
- Changes error code from `PTR_ERR()` extraction to fixed `-EINVAL`
- **No architectural changes**: No struct modifications, no API
additions
- **No new features**: Only error handling standardization
#### 6. **Backport Risk Assessment**
- **Risk level**: LOW
- Changes are localized to error handling paths
- Makes behavior consistent with header stub
- No complex dependencies identified
- Code structure in v6.6 is compatible (verified)
- **Regression potential**: Minimal
- Affects only error paths that were already broken
- Improves consistency between header and implementation
- All callers updated in same commit
#### 7. **Stable Tree Compliance**
- ✅ **Fixes important bug**: Kernel crash
- ✅ **Small and contained**: 2 files, error handling only
- ✅ **No new features**: Pure bug fix
- ✅ **No architectural changes**: No struct/API changes
- ✅ **Obvious and correct**: Crash trace in commit message proves the
fix
- ✅ **Self-contained**: No dependencies on other commits
- ❌ **Missing stable tags**: No "Cc: stable@vger.kernel.org" or "Fixes:"
tag (oversight)
### Specific Code Reference Points:
1. **drivers/soc/ti/knav_dma.c:407-487**: Changed all error returns from
`(void *)-EINVAL` to `NULL`
2. **drivers/net/ethernet/ti/netcp_core.c:1339**: Changed from
`IS_ERR(tx_pipe->dma_channel)` to `!tx_pipe->dma_channel`
3. **drivers/net/ethernet/ti/netcp_core.c:1361**: Changed from
`IS_ERR_OR_NULL()` to simple NULL check in cleanup
4. **drivers/net/ethernet/ti/netcp_core.c:1680**: Changed from
`IS_ERR(netcp->rx_channel)` to `!netcp->rx_channel`
### Conclusion:
This commit is an **excellent candidate for stable backporting**:
- Fixes a real, user-triggerable kernel crash with documented stack
trace
- Affects users of TI Keystone SoCs who configure network interfaces
- Small, well-contained, low-risk change
- Bug has existed since v4.12 (2017) affecting all stable trees
- Should be backported to all active stable kernels (at minimum v6.1+,
v6.6+, v6.12+)
The absence of stable/Fixes tags appears to be an oversight and should
not prevent backporting given the clear evidence of crash and the
straightforward nature of the fix.
drivers/net/ethernet/ti/netcp_core.c | 10 +++++-----
drivers/soc/ti/knav_dma.c | 14 +++++++-------
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/ti/netcp_core.c b/drivers/net/ethernet/ti/netcp_core.c
index 857820657bac5..5ee13db568f08 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -1338,10 +1338,10 @@ int netcp_txpipe_open(struct netcp_tx_pipe *tx_pipe)
tx_pipe->dma_channel = knav_dma_open_channel(dev,
tx_pipe->dma_chan_name, &config);
- if (IS_ERR(tx_pipe->dma_channel)) {
+ if (!tx_pipe->dma_channel) {
dev_err(dev, "failed opening tx chan(%s)\n",
tx_pipe->dma_chan_name);
- ret = PTR_ERR(tx_pipe->dma_channel);
+ ret = -EINVAL;
goto err;
}
@@ -1359,7 +1359,7 @@ int netcp_txpipe_open(struct netcp_tx_pipe *tx_pipe)
return 0;
err:
- if (!IS_ERR_OR_NULL(tx_pipe->dma_channel))
+ if (tx_pipe->dma_channel)
knav_dma_close_channel(tx_pipe->dma_channel);
tx_pipe->dma_channel = NULL;
return ret;
@@ -1678,10 +1678,10 @@ static int netcp_setup_navigator_resources(struct net_device *ndev)
netcp->rx_channel = knav_dma_open_channel(netcp->netcp_device->device,
netcp->dma_chan_name, &config);
- if (IS_ERR(netcp->rx_channel)) {
+ if (!netcp->rx_channel) {
dev_err(netcp->ndev_dev, "failed opening rx chan(%s\n",
netcp->dma_chan_name);
- ret = PTR_ERR(netcp->rx_channel);
+ ret = -EINVAL;
goto fail;
}
diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
index a25ebe6cd5030..553ae7ee20f16 100644
--- a/drivers/soc/ti/knav_dma.c
+++ b/drivers/soc/ti/knav_dma.c
@@ -402,7 +402,7 @@ static int of_channel_match_helper(struct device_node *np, const char *name,
* @name: slave channel name
* @config: dma configuration parameters
*
- * Returns pointer to appropriate DMA channel on success or error.
+ * Return: Pointer to appropriate DMA channel on success or NULL on error.
*/
void *knav_dma_open_channel(struct device *dev, const char *name,
struct knav_dma_cfg *config)
@@ -414,13 +414,13 @@ void *knav_dma_open_channel(struct device *dev, const char *name,
if (!kdev) {
pr_err("keystone-navigator-dma driver not registered\n");
- return (void *)-EINVAL;
+ return NULL;
}
chan_num = of_channel_match_helper(dev->of_node, name, &instance);
if (chan_num < 0) {
dev_err(kdev->dev, "No DMA instance with name %s\n", name);
- return (void *)-EINVAL;
+ return NULL;
}
dev_dbg(kdev->dev, "initializing %s channel %d from DMA %s\n",
@@ -431,7 +431,7 @@ void *knav_dma_open_channel(struct device *dev, const char *name,
if (config->direction != DMA_MEM_TO_DEV &&
config->direction != DMA_DEV_TO_MEM) {
dev_err(kdev->dev, "bad direction\n");
- return (void *)-EINVAL;
+ return NULL;
}
/* Look for correct dma instance */
@@ -443,7 +443,7 @@ void *knav_dma_open_channel(struct device *dev, const char *name,
}
if (!dma) {
dev_err(kdev->dev, "No DMA instance with name %s\n", instance);
- return (void *)-EINVAL;
+ return NULL;
}
/* Look for correct dma channel from dma instance */
@@ -463,14 +463,14 @@ void *knav_dma_open_channel(struct device *dev, const char *name,
if (!chan) {
dev_err(kdev->dev, "channel %d is not in DMA %s\n",
chan_num, instance);
- return (void *)-EINVAL;
+ return NULL;
}
if (atomic_read(&chan->ref_count) >= 1) {
if (!check_config(chan, config)) {
dev_err(kdev->dev, "channel %d config miss-match\n",
chan_num);
- return (void *)-EINVAL;
+ return NULL;
}
}
--
2.51.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH AUTOSEL 6.17] scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)
2025-11-10 19:57 [PATCH AUTOSEL 6.17-6.12] drm/amdgpu: fix gpu page fault after hibernation on PF passthrough Sasha Levin
2025-11-10 19:57 ` [PATCH AUTOSEL 6.17-5.15] tracing/tools: Fix incorrcet short option in usage text for --threads Sasha Levin
2025-11-10 19:57 ` [PATCH AUTOSEL 6.17-5.4] net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Sasha Levin
@ 2025-11-10 19:57 ` Sasha Levin
2025-11-10 19:57 ` [PATCH AUTOSEL 6.17] btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name Sasha Levin
2025-11-10 19:57 ` [PATCH AUTOSEL 6.17-6.12] drm/xe: Move declarations under conditional branch Sasha Levin
4 siblings, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2025-11-10 19:57 UTC (permalink / raw)
To: patches, stable
Cc: Nitin Rawat, Manivannan Sadhasivam, Martin K. Petersen,
Sasha Levin, linux-arm-msm, linux-scsi
From: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
[ Upstream commit 5127be409c6c3815c4a7d8f6d88043e44f9b9543 ]
According to UFS specifications, the power-off sequence for a UFS device
includes:
- Sending an SSU command with Power_Condition=3 and await a response.
- Asserting RST_N low.
- Turning off REF_CLK.
- Turning off VCC.
- Turning off VCCQ/VCCQ2.
As part of ufs shutdown, after the SSU command completion, asserting
hardware reset (HWRST) triggers the device firmware to wake up and
execute its reset routine. This routine initializes hardware blocks and
takes a few milliseconds to complete. During this time, the ICCQ draws a
large current.
This large ICCQ current may cause issues for the regulator which is
supplying power to UFS, because the turn off request from UFS driver to
the regulator framework will be immediately followed by low power
mode(LPM) request by regulator framework. This is done by framework
because UFS which is the only client is requesting for disable. So if
the rail is still in the process of shutting down while ICCQ exceeds LPM
current thresholds, and LPM mode is activated in hardware during this
state, it may trigger an overcurrent protection (OCP) fault in the
regulator.
To prevent this, a 10ms delay is added after asserting HWRST. This
allows the reset operation to complete while power rails remain active
and in high-power mode.
Currently there is no way for Host to query whether the reset is
completed or not and hence this the delay is based on experiments with
Qualcomm UFS controllers across multiple UFS vendors.
Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20251012173828.9880-1-nitin.rawat@oss.qualcomm.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 comprehensive analysis using semantic code analysis tools
and repository examination, here is my assessment:
## BACKPORT RECOMMENDATION: YES
## Analysis Summary
### Semantic Analysis Tools Used:
1. **mcp__semcode__find_function** - Located the `ufs_qcom_suspend` and
`ufs_qcom_device_reset_ctrl` functions
2. **mcp__semcode__find_callers** - Found that
`ufs_qcom_device_reset_ctrl` is called by only 2 functions, making
impact analysis straightforward
3. **mcp__semcode__find_callchain** - Traced the call path showing this
is invoked through variant ops during system suspend
4. **mcp__semcode__diff_functions** - Confirmed this is a minimal
semantic change (just adding a delay)
5. **git log/blame analysis** - Traced the historical context
### Key Findings:
#### 1. **Impact & Scope Analysis**
- **Function location**: `drivers/ufs/host/ufs-qcom.c:731` in
`ufs_qcom_suspend()`
- **Call graph**: The function is registered as a suspend callback in
`ufs_hba_variant_ops` and gets invoked during system suspend
operations
- **Affected devices**: All Qualcomm UFS controllers (MSM8994, MSM8996,
SDM845, SM8150, SM8250, SM8350, SM8450, SM8550, SM8650, SM8750, and
many more)
- **User exposure**: HIGH - triggered during normal suspend/resume
cycles
#### 2. **Code Change Analysis**
The change is extremely minimal and low-risk:
```c
if (ufs_qcom_is_link_off(hba) && host->device_reset) {
ufs_qcom_device_reset_ctrl(hba, true);
+ usleep_range(10000, 11000); // Only change: 10ms delay
}
```
#### 3. **Historical Context**
- The device reset during suspend was introduced in **v5.12-rc1**
(commit b61d041413685, Jan 2021)
- This OCP issue has existed for **~4 years**
- Not a recent regression - this is a long-standing hardware timing
issue
#### 4. **Problem Severity**
According to the commit message and code analysis:
- **Issue**: After asserting hardware reset, the UFS device firmware
wakes up and draws large ICCQ current
- **Consequence**: Can trigger overcurrent protection (OCP) faults in
the regulator hardware
- **Impact**: Potential hardware protection faults during power down
sequence
- **Root cause**: Race between device reset completion and regulator
entering low-power mode
#### 5. **Risk Assessment**
- **Regression risk**: VERY LOW - only adds a 10ms sleep
- **Side effects**: None beyond slightly longer suspend time (10ms is
negligible)
- **Dependencies**: No new dependencies introduced
- **Architectural changes**: None
### Reasoning for YES:
1. **Fixes important hardware issue**: Prevents OCP faults that could
affect regulator hardware integrity
2. **Wide device impact**: Affects entire Qualcomm UFS ecosystem (very
popular in Android devices)
3. **Long-standing bug**: Has existed since v5.12 (2021), not a new
feature
4. **Minimal and safe**: Single-line change with no complex logic
5. **Follows stable rules**:
- ✓ It fixes a bug
- ✓ Obviously correct
- ✓ Small and contained
- ✓ Doesn't add new features
- ✓ Low regression risk
### Notable Observations:
- **No explicit stable tag**: The commit does NOT include "Cc:
stable@vger.kernel.org", which typically indicates maintainers didn't
prioritize it for backport
- **Cautious language**: Commit uses "may cause" rather than "causes" -
suggesting this is a potential issue rather than frequently reported
problem
- **No user reports mentioned**: No indication of widespread user-
visible failures
### Recommendation:
**YES - Backport to stable kernels 5.12+**
Despite the lack of explicit stable tag, this commit should be
backported because:
- It prevents potential hardware protection faults
- The fix is trivial and risk-free
- It affects a critical subsystem (storage) on widely-used platforms
- The issue has existed for years across all Qualcomm UFS devices
Priority: **MEDIUM** - This is a valid fix for a hardware timing issue,
but the lack of stable tag and cautious commit language suggests it's
not causing widespread failures. However, preventing OCP faults is
important for hardware longevity.
drivers/ufs/host/ufs-qcom.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 9574fdc2bb0fd..8fe4405ec0ec7 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -741,8 +741,21 @@ static int ufs_qcom_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op,
/* reset the connected UFS device during power down */
- if (ufs_qcom_is_link_off(hba) && host->device_reset)
+ if (ufs_qcom_is_link_off(hba) && host->device_reset) {
ufs_qcom_device_reset_ctrl(hba, true);
+ /*
+ * After sending the SSU command, asserting the rst_n
+ * line causes the device firmware to wake up and
+ * execute its reset routine.
+ *
+ * During this process, the device may draw current
+ * beyond the permissible limit for low-power mode (LPM).
+ * A 10ms delay, based on experimental observations,
+ * allows the UFS device to complete its hardware reset
+ * before transitioning the power rail to LPM.
+ */
+ usleep_range(10000, 11000);
+ }
return ufs_qcom_ice_suspend(host);
}
--
2.51.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH AUTOSEL 6.17] btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name
2025-11-10 19:57 [PATCH AUTOSEL 6.17-6.12] drm/amdgpu: fix gpu page fault after hibernation on PF passthrough Sasha Levin
` (2 preceding siblings ...)
2025-11-10 19:57 ` [PATCH AUTOSEL 6.17] scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3) Sasha Levin
@ 2025-11-10 19:57 ` Sasha Levin
2025-11-10 19:57 ` [PATCH AUTOSEL 6.17-6.12] drm/xe: Move declarations under conditional branch Sasha Levin
4 siblings, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2025-11-10 19:57 UTC (permalink / raw)
To: patches, stable
Cc: Filipe Manana, Vyacheslav Kovalevsky, Boris Burkov, Qu Wenruo,
David Sterba, Sasha Levin, clm, linux-btrfs
From: Filipe Manana <fdmanana@suse.com>
[ Upstream commit 953902e4fb4c373c81a977f78e40f9f93a79e20f ]
If we are logging a new name make sure our inode has the runtime flag
BTRFS_INODE_COPY_EVERYTHING set so that at btrfs_log_inode() we will find
new inode refs/extrefs in the subvolume tree and copy them into the log
tree.
We are currently doing it when adding a new link but we are missing it
when renaming.
An example where this makes a new name not persisted:
1) create symlink with name foo in directory A
2) fsync directory A, which persists the symlink
3) rename the symlink from foo to bar
4) fsync directory A to persist the new symlink name
Step 4 isn't working correctly as it's not logging the new name and also
leaving the old inode ref in the log tree, so after a power failure the
symlink still has the old name of "foo". This is because when we first
fsync directoy A we log the symlink's inode (as it's a new entry) and at
btrfs_log_inode() we set the log mode to LOG_INODE_ALL and then because
we are using that mode and the inode has the runtime flag
BTRFS_INODE_NEEDS_FULL_SYNC set, we clear that flag as well as the flag
BTRFS_INODE_COPY_EVERYTHING. That means the next time we log the inode,
during the rename through the call to btrfs_log_new_name() (calling
btrfs_log_inode_parent() and then btrfs_log_inode()), we will not search
the subvolume tree for new refs/extrefs and jump directory to the
'log_extents' label.
Fix this by making sure we set BTRFS_INODE_COPY_EVERYTHING on an inode
when we are about to log a new name. A test case for fstests will follow
soon.
Reported-by: Vyacheslav Kovalevsky <slava.kovalevskiy.2014@gmail.com>
Link: https://lore.kernel.org/linux-btrfs/ac949c74-90c2-4b9a-b7fd-1ffc5c3175c7@gmail.com/
Reviewed-by: Boris Burkov <boris@bur.io>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Backport Recommendation
**YES** - This commit should be backported to stable kernel trees.
## Analysis Summary
### 1. Semantic Code Analysis Tools Used
I employed the following semantic analysis tools to thoroughly evaluate
this commit:
- **mcp__semcode__find_function**: Located `btrfs_log_new_name`,
`btrfs_link`, `btrfs_log_inode`, `btrfs_rename`, and `btrfs_rename2`
to understand the affected code paths
- **mcp__semcode__find_callers**: Traced the call graph to identify that
`btrfs_log_new_name` is called by:
- `btrfs_link` (fs/btrfs/inode.c:6808)
- `btrfs_rename` (fs/btrfs/inode.c:8339)
- `btrfs_rename_exchange` (fs/btrfs/inode.c:8054)
- **mcp__semcode__grep_functions**: Searched for usage patterns of
`BTRFS_INODE_COPY_EVERYTHING` flag across the codebase
- **Git history analysis**: Examined commit history to understand the
bug's age and evolution
### 2. Impact Scope Analysis
**User-Space Reachability: HIGH**
- The bug is directly reachable from user-space through standard system
calls:
- `rename()` / `renameat()` / `renameat2()` → VFS layer →
`btrfs_rename2` → `btrfs_rename` or `btrfs_rename_exchange` →
`btrfs_log_new_name`
- `link()` → VFS layer → `btrfs_link` → `btrfs_log_new_name`
**Caller Analysis Results:**
- `btrfs_rename2` is a VFS inode operation callback (no callers = VFS
entry point)
- 3 direct callers of `btrfs_log_new_name`: all filesystem operations
- This indicates high exposure to user workloads
**Real-World Impact:**
- Confirmed user bug report from Vyacheslav Kovalevsky showing data
persistence failures
- Affects crash consistency: renamed files revert to old names after
system crashes
- Other filesystems (ext4, xfs, nilfs2) handle this correctly, making
btrfs behavior incorrect
- Primarily affects symlinks but could impact other file types
### 3. Code Change Analysis
**Scope: VERY SMALL AND CONTAINED**
The fix consists of only 3 effective lines across 2 files:
**fs/btrfs/tree-log.c (ADD 2 lines):**
```c
/* The inode has a new name (ref/extref), so make sure we log it. */
set_bit(BTRFS_INODE_COPY_EVERYTHING, &inode->runtime_flags);
```
**fs/btrfs/inode.c (REMOVE 1 line):**
```c
- set_bit(BTRFS_INODE_COPY_EVERYTHING, &BTRFS_I(inode)->runtime_flags);
```
The change **moves** flag setting from `btrfs_link()` to
`btrfs_log_new_name()`, ensuring the flag is set for **both** link and
rename operations, not just links.
### 4. Semantic Change Analysis
**Using mcp__semcode__diff_functions findings:**
The fix is a **behavioral correction**, not a refactoring:
- **Before**: `BTRFS_INODE_COPY_EVERYTHING` flag was only set during
`btrfs_link()` operations
- **After**: Flag is set in `btrfs_log_new_name()`, covering both link
AND rename operations
- **Effect**: When `btrfs_log_inode()` runs, it now correctly searches
the subvolume tree for new inode refs/extrefs during rename operations
**Root Cause Identified:**
When a directory is first fsynced with a new file, `btrfs_log_inode()`
sets `LOG_INODE_ALL` mode and clears both `BTRFS_INODE_NEEDS_FULL_SYNC`
and `BTRFS_INODE_COPY_EVERYTHING` flags. On subsequent rename+fsync
operations, without `BTRFS_INODE_COPY_EVERYTHING` set, the logging code
jumps directly to `log_extents` label, skipping the critical step of
copying new refs/extrefs to the log tree.
### 5. Dependency Analysis
**Using mcp__semcode__find_calls findings:**
- No new functions introduced
- No API changes required
- No data structure modifications
- The `BTRFS_INODE_COPY_EVERYTHING` flag has existed since at least 2015
(commit a742994aa2e27)
- No complex dependency chains that would complicate backporting
**Backport Risk: MINIMAL**
- The code structure in stable kernels should be similar enough for
clean application
- Some recent refactoring exists (commits da7ad2ec580b8, 841324a8e60b2,
93612a92bade2) but these are upstream changes that may already be in
stable trees
- The core logic being fixed is long-standing
### 6. Bug Characteristics
**Type:** Data persistence / crash consistency bug
**Severity:** HIGH - Data integrity issue
**Age:** Long-standing (related code from 2015+)
**Reproducibility:** Confirmed with specific test case
**Subsystem:** Btrfs filesystem - tree-log (fsync path)
### 7. Stable Tree Compliance Check
✅ **Bug fix** (not a new feature)
✅ **Small, contained change** (3 lines, 2 files)
✅ **Fixes user-visible problem** (confirmed bug report)
✅ **Minimal regression risk** (simple flag management)
✅ **No architectural changes**
✅ **No new dependencies**
✅ **Affects data integrity** (HIGH PRIORITY)
**Notable Observations:**
- ❌ No `Cc: stable@vger.kernel.org` tag (possible oversight)
- ❌ No `Fixes:` tag (unusual for a bug fix)
- ✅ Has `Reported-by:` with real user impact
- ✅ Has multiple `Reviewed-by:` tags (Boris Burkov, Qu Wenruo)
### 8. Why This Is An Excellent Backport Candidate
1. **Clear bug with user impact**: Real-world bug report showing data
loss scenario
2. **Minimal code change**: Moving a single flag assignment to correct
location
3. **No side effects**: Fix purely addresses the reported issue without
behavioral changes elsewhere
4. **Long-standing bug**: Has existed for years, affecting all stable
kernels with btrfs
5. **High confidence fix**: Reviewed by multiple btrfs maintainers
6. **Data integrity issue**: Violates fsync durability guarantees that
applications depend on
7. **Clean backport**: No complex dependencies or API changes required
### Recommendation
**This commit MUST be backported to all stable kernel trees that support
btrfs.** The absence of stable tags appears to be an oversight rather
than intentional exclusion. The fix addresses a clear data integrity bug
with minimal risk and should be prioritized for stable inclusion.
fs/btrfs/inode.c | 1 -
fs/btrfs/tree-log.c | 3 +++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 41da405181b4f..b0e0d8711d127 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -6848,7 +6848,6 @@ static int btrfs_link(struct dentry *old_dentry, struct inode *dir,
BTRFS_I(inode)->dir_index = 0ULL;
inode_inc_iversion(inode);
inode_set_ctime_current(inode);
- set_bit(BTRFS_INODE_COPY_EVERYTHING, &BTRFS_I(inode)->runtime_flags);
ret = btrfs_add_link(trans, BTRFS_I(dir), BTRFS_I(inode),
&fname.disk_name, 1, index);
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 165d2ee500ca3..410fb1b3f26c2 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -7608,6 +7608,9 @@ void btrfs_log_new_name(struct btrfs_trans_handle *trans,
bool log_pinned = false;
int ret;
+ /* The inode has a new name (ref/extref), so make sure we log it. */
+ set_bit(BTRFS_INODE_COPY_EVERYTHING, &inode->runtime_flags);
+
btrfs_init_log_ctx(&ctx, inode);
ctx.logging_new_name = true;
--
2.51.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH AUTOSEL 6.17-6.12] drm/xe: Move declarations under conditional branch
2025-11-10 19:57 [PATCH AUTOSEL 6.17-6.12] drm/amdgpu: fix gpu page fault after hibernation on PF passthrough Sasha Levin
` (3 preceding siblings ...)
2025-11-10 19:57 ` [PATCH AUTOSEL 6.17] btrfs: set inode flag BTRFS_INODE_COPY_EVERYTHING when logging new name Sasha Levin
@ 2025-11-10 19:57 ` Sasha Levin
4 siblings, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2025-11-10 19:57 UTC (permalink / raw)
To: patches, stable
Cc: Tejas Upadhyay, Nitin Gote, Lucas De Marchi, Sasha Levin,
thomas.hellstrom, rodrigo.vivi, intel-xe
From: Tejas Upadhyay <tejas.upadhyay@intel.com>
[ Upstream commit 9cd27eec872f0b95dcdd811edc39d2d32e4158c8 ]
The xe_device_shutdown() function was needing a few declarations
that were only required under a specific condition. This change
moves those declarations to be within that conditional branch
to avoid unnecessary declarations.
Reviewed-by: Nitin Gote <nitin.r.gote@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251007100208.1407021-1-tejas.upadhyay@intel.com
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
(cherry picked from commit 15b3036045188f4da4ca62b2ed01b0f160252e9b)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Based on my analysis using semantic code analysis tools and git
repository examination, here is my assessment:
## Answer: YES
## Detailed Analysis:
### 1. Semantic Analysis Tools Used:
**mcp__semcode__find_function**: Located the `xe_device_shutdown`
function in drivers/gpu/drm/xe/xe_device.c:963-983
**mcp__semcode__find_callers**: Identified that `xe_device_shutdown` is
called by `xe_pci_shutdown` (the PCI device shutdown handler at
drivers/gpu/drm/xe/xe_pci.c:877)
**mcp__semcode__diff_functions**: Attempted to analyze semantic
differences in the diff
**Git history analysis**: Examined the commit chain and discovered the
critical dependency relationship
### 2. Key Findings:
**This commit is explicitly marked as a stable dependency** for commit
b11a020d914c3 ("drm/xe: Do clean shutdown also when using flr"). The git
log shows:
```
Stable-dep-of: b11a020d914c ("drm/xe: Do clean shutdown also when using
flr")
```
**The dependent bug fix (b11a020d914c3)**:
- Fixes a real bug causing "random warnings from pending related works
as the underlying hardware is reset in the middle of their execution"
- Has a `Fixes:` tag pointing to 501d799a47e2 ("drm/xe: Wire up device
shutdown handler")
- Includes `Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>`
indicating maintainer involvement
- Is already cherry-picked and destined for stable trees
### 3. Code Change Analysis:
**What this commit does**:
- Moves variable declarations (`struct xe_gt *gt` and `u8 id`) from
function start into the conditional block where they're actually used
- Purely a code organization change with **zero behavioral impact**
- Changes from:
```c
void xe_device_shutdown(struct xe_device *xe) {
struct xe_gt *gt; // Declared at top
u8 id;
if (xe_driver_flr_disabled(xe)) {
// use gt and id here
}
}
```
To:
```c
void xe_device_shutdown(struct xe_device *xe) {
if (xe_driver_flr_disabled(xe)) {
struct xe_gt *gt; // Declared inside conditional
u8 id;
// use gt and id here
}
}
```
### 4. Impact Scope:
- **Affected function**: Single function `xe_device_shutdown` in xe DRM
driver
- **Call path**: User shutdown/reboot → PCI shutdown handler →
xe_pci_shutdown → xe_device_shutdown
- **Risk level**: Minimal - this is a refactoring that doesn't change
behavior
- **Subsystem**: Intel Xe GPU driver (drm/xe) - not a core kernel
subsystem
### 5. Why This Should Be Backported:
**Primary Reason**: **Stable Dependency Requirement**
- The subsequent bug fix b11a020d914c3 needs this commit for clean
application
- Without it, the bug fix patch may have context conflicts or require
manual adjustment
- Stable tree maintainers have already identified this as a required
dependency
**Secondary Reasons**:
- **Zero risk**: Pure code movement with no behavioral change
- **Small scope**: Single function in a device driver
- **Cherry-picked**: Already cherry-picked with signature `(cherry
picked from commit 15b3036045188f4da4ca62b2ed01b0f160252e9b)`
- **Enables important fix**: Required for fixing shutdown warnings that
affect users
### 6. Stable Tree Rules Compliance:
✅ **Fixes real issue** (as a dependency for an actual bug fix)
✅ **Small and contained** (single function, declaration movement)
✅ **No new features** (refactoring only)
✅ **Low regression risk** (no behavioral change)
✅ **Explicitly marked for stable** (Stable-dep-of tag)
### Conclusion:
This commit should be backported to stable trees because it is
explicitly marked as a stable dependency for an important bug fix. While
it doesn't fix a bug itself, it's a necessary prerequisite that ensures
the subsequent fix (b11a020d914c3) applies cleanly. The change is safe
(zero behavioral impact), small (single function), and already
identified by maintainers as required for stable tree integration.
drivers/gpu/drm/xe/xe_device.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 1c9907b8a4e9e..e7f838fed3298 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -962,12 +962,12 @@ void xe_device_remove(struct xe_device *xe)
void xe_device_shutdown(struct xe_device *xe)
{
- struct xe_gt *gt;
- u8 id;
-
drm_dbg(&xe->drm, "Shutting down device\n");
if (xe_driver_flr_disabled(xe)) {
+ struct xe_gt *gt;
+ u8 id;
+
xe_display_pm_shutdown(xe);
xe_irq_suspend(xe);
--
2.51.0
^ permalink raw reply related [flat|nested] 6+ messages in thread