From: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
To: Bartosz Golaszewski <brgl@kernel.org>, Linus Walleij <linusw@kernel.org>
Cc: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
Kent Gibson <warthog618@gmail.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Herve Codina <herve.codina@bootlin.com>,
Jia Jia <physicalmtea@gmail.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: [PATCH 2/6] gpiolib: free the label of lines released after their chip was removed
Date: Mon, 12 Oct 2026 16:49:56 +0300 [thread overview]
Message-ID: <20261012-gpiolib-chip-removal-v1-2-aambrozewicz@nvidia.com> (raw)
In-Reply-To: <20261012-gpiolib-chip-removal-v1-0-aambrozewicz@nvidia.com>
gpiod_free_commit() only drops the consumer label while the chip is
still there:
if (guard.gc && test_bit(GPIOD_FLAG_REQUESTED, &flags)) {
...
desc_set_label(desc, NULL);
A line that is still requested when gpiochip_remove() runs, for instance
by a character device line request that user space keeps open, is
released only afterwards, when gdev->chip is already NULL. Its label is
then never freed, as gpiodev_release() frees the descriptor array but
not the labels, and kmemleak reports one object per such line:
unreferenced object 0xff110000057b63c0 (size 32):
comm "gpio-hold", pid 111, jiffies 4294696675
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
3f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?...............
backtrace (crc 7ff222d9):
__kmalloc_noprof+0x4ee/0x670
desc_set_label+0x32/0x110
gpiod_request_commit+0x1dd/0x320
gpiod_request+0x28/0x100
linereq_create+0x61a/0xce0
gpio_ioctl+0x49c/0xc80
__x64_sys_ioctl+0x134/0x1c0
do_syscall_64+0x109/0x5d0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Commit 1f2bcb8c8ccd ("gpio: protect the descriptor label with SRCU")
cleared the label unconditionally; it moved under the chip check with
the removal of gpio_lock. Clear it when the chip is gone as well. The
->free() callback and the line state notification still need the chip
and stay where they are.
The label is now often freed just before the last reference to the GPIO
device goes away, which depends on gpiodev_release() waiting for pending
label frees (previous patch).
Reproduced with gpio-sim: request a line through the character device,
set the chip's configfs "live" attribute to 0 while the request is open,
then close it. Without this change kmemleak reports between 15 and 30
such objects after 30 cycles; with it, none after 100.
Fixes: 35b545332b80 ("gpio: remove gpio_lock")
Cc: stable@vger.kernel.org
Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
---
drivers/gpio/gpiolib.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 1984f3416437..750378f3907a 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2689,6 +2689,9 @@ void gpiod_free_commit(struct gpio_desc *desc)
WRITE_ONCE(desc->debounce_period_us, 0);
#endif
gpiod_line_state_notify(desc, GPIO_V2_LINE_CHANGED_RELEASED);
+ } else if (!guard.gc) {
+ /* The chip is gone but the consumer label is still ours. */
+ desc_set_label(desc, NULL);
}
}
--
2.43.0
next prev parent reply other threads:[~2026-10-12 13:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 13:49 [PATCH 0/6] gpiolib: fix chip removal with lines still requested from user space Adrian Ambrozewicz
2026-10-12 13:49 ` [PATCH 1/6] gpiolib: wait for pending label frees before cleaning up desc_srcu Adrian Ambrozewicz
2026-10-12 15:46 ` Paul E. McKenney
2026-10-16 7:46 ` Adrian Ambrozewicz
2026-10-12 20:42 ` Andy Shevchenko
2026-10-16 7:46 ` Adrian Ambrozewicz
2026-10-12 13:49 ` Adrian Ambrozewicz [this message]
2026-10-13 15:38 ` [PATCH 2/6] gpiolib: free the label of lines released after their chip was removed Andy Shevchenko
2026-10-16 7:46 ` Adrian Ambrozewicz
2026-10-12 13:49 ` [PATCH 3/6] gpiolib: cdev: do not free line IRQs again after the chip is removed Adrian Ambrozewicz
2026-10-13 15:44 ` Andy Shevchenko
2026-10-16 7:46 ` Adrian Ambrozewicz
2026-10-12 13:49 ` [PATCH 4/6] gpiolib: cdev: don't sleep in the SRCU read section in read() Adrian Ambrozewicz
2026-10-13 15:48 ` Andy Shevchenko
2026-10-16 7:46 ` Adrian Ambrozewicz
2026-10-12 13:49 ` [PATCH 5/6] gpiolib: cdev: don't leak the IRQ name when the chip is removed Adrian Ambrozewicz
2026-10-13 15:59 ` Andy Shevchenko
2026-10-16 7:46 ` Adrian Ambrozewicz
2026-10-12 13:50 ` [PATCH 6/6] gpiolib: let the character device free its IRQs first on chip removal Adrian Ambrozewicz
2026-10-13 16:05 ` Andy Shevchenko
2026-10-16 7:46 ` Adrian Ambrozewicz
2026-10-15 12:57 ` [PATCH 0/6] gpiolib: fix chip removal with lines still requested from user space Bartosz Golaszewski
2026-10-16 7:46 ` Adrian Ambrozewicz
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=20261012-gpiolib-chip-removal-v1-2-aambrozewicz@nvidia.com \
--to=aambrozewicz@nvidia.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=herve.codina@bootlin.com \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=physicalmtea@gmail.com \
--cc=stable@vger.kernel.org \
--cc=warthog618@gmail.com \
/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
all inboxes | Powered by JetHome®