public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>,
	Mark Brown <broonie@kernel.org>, Sasha Levin <sashal@kernel.org>,
	lgirdwood@gmail.com, linux-kernel@vger.kernel.org
Subject: [PATCH AUTOSEL 6.19-6.18] regulator: core: Remove regulator supply_name length limit
Date: Mon, 23 Feb 2026 07:37:16 -0500	[thread overview]
Message-ID: <20260223123738.1532940-11-sashal@kernel.org> (raw)
In-Reply-To: <20260223123738.1532940-1-sashal@kernel.org>

From: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>

[ Upstream commit e243cdd87b911ce9968b62e4ab2b680dfadc4341 ]

When creating the regulator object, associated with a consumer device,
the supply_name is string formatted into a statically sized buffer on
the stack, then strdup()'ed onto the heap.

Not only is the dance on the stack unnecessary, but when the device's
name is long we might not fit the constructed supply_name in the fixed
64 byte buffer on the stack.

One such case can be seen on the Qualcomm Rb3Gen2 board, where we find a
PCIe controller, with a PCIe switch, with a USB controller, with a USB
hub, consuming a regulator. In this example the dev->kobj.name itself is
62 characters long.

Drop the temporary buffer on the stack and kasprintf() the string
directly on the heap, both to simplify the code, and to remove the
length limitation.

Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Link: https://patch.msgid.link/20260211-regulator-supply-name-length-v1-1-3875541c1576@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have sufficient information for a thorough analysis.

## Analysis

### 1. COMMIT MESSAGE ANALYSIS

The commit message clearly describes a real bug: the
`create_regulator()` function uses a fixed 64-byte stack buffer
(`REG_STR_SIZE`) to format the supply name. When the device's kobject
name plus the supply name exceeds 63 characters, the `snprintf` output
is truncated, and the `size >= REG_STR_SIZE` check causes the function
to return NULL — meaning the regulator **fails to be created entirely**.

The commit describes a concrete real-world case on the Qualcomm Rb3Gen2
board where a deeply nested device topology (PCIe controller -> PCIe
switch -> USB controller -> USB hub) produces a device name 62
characters long, which combined with the supply name easily exceeds 64
bytes.

### 2. CODE CHANGE ANALYSIS

The change is small and surgical:

**Before:** A 64-byte stack buffer `buf[REG_STR_SIZE]` is used with
`snprintf()`, then `kstrdup()`. If the formatted string is >= 64 bytes,
the function returns NULL (regulator creation fails).

**After:** `kasprintf(GFP_KERNEL, "%s-%s", dev->kobj.name, supply_name)`
allocates exactly the needed size on the heap directly. No truncation
possible (unless memory allocation itself fails).

The change:
- Removes the `#define REG_STR_SIZE 64` (which was only used here)
- Removes the stack buffer and `snprintf` + truncation check + `kstrdup`
  dance
- Replaces with a single `kasprintf()` call
- Keeps the `kfree_const()` cleanup compatible (kasprintf returns heap
  memory, which kfree_const handles correctly)

### 3. USER IMPACT

When `create_regulator()` returns NULL, both callers (`set_supply()` at
line 1798, and `_regulator_get_common()` at line 2411) treat it as
-ENOMEM and fail the regulator acquisition. This means:

- **In `set_supply()`**: The regulator's supply chain fails to resolve.
  The regulator won't work properly.
- **In `_regulator_get_common()`**: `regulator_get()` returns an error
  to the consumer driver. The driver's probe will fail, meaning the
  device won't function.

On the Qualcomm Rb3Gen2, this means a USB hub behind a PCIe-connected
USB controller can't get its regulator, potentially causing the entire
downstream USB tree to be non-functional.

### 4. SCOPE AND RISK

- **Lines changed**: ~15 lines removed, ~3 lines added (net reduction)
- **Files affected**: 1 file (drivers/regulator/core.c)
- **Risk**: Very low. `kasprintf` is a well-established kernel API. The
  change is semantically equivalent but removes an arbitrary limitation.
  The only functional difference is: names that were previously rejected
  (>63 chars) now succeed.
- **Regression potential**: Minimal. The new code handles the same error
  cases (memory allocation failure). The `kfree_const` in
  `destroy_regulator()` works correctly with both `kasprintf` and
  `kstrdup_const` allocated memory.

### 5. STABLE KERNEL CRITERIA

- **Obviously correct**: Yes — `kasprintf` is the standard kernel
  pattern for "format a string and allocate it"
- **Fixes a real bug**: Yes — regulator creation silently fails for
  devices with long names
- **Important issue**: Yes — complete device failure on affected
  hardware
- **Small and contained**: Yes — 1 file, ~15 lines net change, purely
  within one function
- **No new features**: Correct — no new API, no behavior change for
  names that fit in 64 bytes
- **No dependencies**: The code uses standard kernel APIs (`kasprintf`,
  `kfree_const`) that exist in all stable trees

### 6. DEPENDENCY CHECK

The commit operates on `create_regulator()` which has existed in the
kernel for a very long time. The `kasprintf` API is available in all
supported stable kernels. The `kfree_const` pattern was introduced in
commit 0630b614391f (2017), so it's in all current stable trees. No
dependencies on other recent commits.

### Verification

- **Verified** that `create_regulator()` is called from `set_supply()`
  (line 1798) and `_regulator_get_common()` (line 2411), both of which
  propagate NULL as -ENOMEM errors that fail driver probe
- **Verified** that `REG_STR_SIZE` was only used in `create_regulator()`
  (via grep)
- **Verified** that `kfree_const()` is used in `destroy_regulator()` to
  free `supply_name`, and works correctly with `kasprintf`-allocated
  memory (heap memory is always freeable by kfree_const)
- **Verified** via git log that `kstrdup_const` pattern was introduced
  in commit 0630b614391f (2017), present in all stable trees
- **Verified** the code before the patch at lines 1996-2004 showing the
  64-byte buffer and truncation-then-return-NULL behavior
- **Verified** the commit applies to a single file
  (drivers/regulator/core.c) with minimal change scope
- **Unverified**: Could not independently verify the 62-character device
  name claim on Rb3Gen2 (taken from commit message, which is from the
  Qualcomm kernel engineer)

### Conclusion

This commit fixes a real bug where regulator creation fails for devices
with long kobject names (>~58 characters when combined with supply
name). The failure causes complete device malfunction. The fix is small,
surgical, uses standard kernel APIs, has no dependencies, and carries
essentially zero regression risk. It meets all stable kernel criteria.

**YES**

 drivers/regulator/core.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 4b6182cde859a..6fb00d21004ed 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1944,8 +1944,6 @@ static const struct file_operations constraint_flags_fops = {
 #endif
 };
 
-#define REG_STR_SIZE	64
-
 static void link_and_create_debugfs(struct regulator *regulator, struct regulator_dev *rdev,
 				    struct device *dev)
 {
@@ -1993,15 +1991,7 @@ static struct regulator *create_regulator(struct regulator_dev *rdev,
 	lockdep_assert_held_once(&rdev->mutex.base);
 
 	if (dev) {
-		char buf[REG_STR_SIZE];
-		int size;
-
-		size = snprintf(buf, REG_STR_SIZE, "%s-%s",
-				dev->kobj.name, supply_name);
-		if (size >= REG_STR_SIZE)
-			return NULL;
-
-		supply_name = kstrdup(buf, GFP_KERNEL);
+		supply_name = kasprintf(GFP_KERNEL, "%s-%s", dev->kobj.name, supply_name);
 		if (supply_name == NULL)
 			return NULL;
 	} else {
-- 
2.51.0


  parent reply	other threads:[~2026-02-23 12:37 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23 12:37 [PATCH AUTOSEL 6.19-6.1] drm/amd/display: Remove conditional for shaper 3DLUT power-on Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.18] ASoC: rt721-sdca: Fix issue of fail to detect OMTP jack type Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.18] ALSA: hda/tas2781: Ignore reset check for SPI device Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-5.15] btrfs: replace BUG() with error handling in __btrfs_balance() Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-5.15] ALSA: usb-audio: Add sanity check for OOB writes at silencing Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.12] drm/amd/display: Fix system resume lag issue Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.12] arm64: hugetlbpage: avoid unused-but-set-parameter warning (gcc-16) Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.12] drm/amd/display: Fix writeback on DCN 3.2+ Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.18] drm/amdgpu: Skip vcn poison irq release on VF Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.18] drm/amdgpu: return when ras table checksum is error Sasha Levin
2026-02-23 12:37 ` Sasha Levin [this message]
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-5.10] ARM: 9467/1: mm: Don't use %pK through printk Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-5.10] drm/radeon: Add HAINAN clock adjustment Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.18] drm/amdgpu: avoid sdma ring reset in sriov Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.12] spi: spidev: fix lock inversion between spi_lock and buf_lock Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-5.15] drm/amdgpu: Adjust usleep_range in fence wait Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19] mshv: Ignore second stats page map result failure Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19] btrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure() Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.18] ALSA: hda/hdmi: Add quirk for TUXEDO IBS14G6 Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19] drm/amd/display: set enable_legacy_fast_update to false for DCN36 Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19] x86/hyperv: Move hv crash init after hypercall pg setup Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.18] mshv: clear eventfd counter on irqfd shutdown Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-5.10] drm/amd/display: Avoid updating surface with the same surface under MPO Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-5.15] ALSA: usb-audio: Update the number of packets properly at receiving Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.12] drm/amd/display: bypass post csc for additional color spaces in dal Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.18] ASoC: amd: amd_sdw: add machine driver quirk for Lenovo models Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: Fix headset mic on ASUS Zenbook 14 UX3405MA Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19] Drivers: hv: vmbus: Use kthread for vmbus interrupts on PREEMPT_RT Sasha Levin
2026-02-23 12:37 ` [PATCH AUTOSEL 6.19-5.10] drm/amdgpu: Add HAINAN clock adjustment Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260223123738.1532940-11-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=bjorn.andersson@oss.qualcomm.com \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox