This change makes the tty device file available only after the tty's backing character device is ready.
Since 6a7e6f78c235975cc14d4e141fa088afffe7062c, the class device is registered before the cdev is created, and userspace may pick it up, yet open() will fail because the backing cdev doesn't exist yet. Userspace is racing the bottom half of tty_register_device_attr() here, specifically the call to tty_cdev_add().
dev_set_uevent_suppress() was used to work around this, but this fails on embedded systems that rely on bare devtmpfs rather than udev. On such systems, the device file is created as part of device_add(), and userspace can pick it up via inotify, irrespective of uevent suppression.
So let's undo the existing patch, and create the cdev first, and only afterwards register the class device in the kernel's device tree.
However, this restores the original race of the cdev existing before the class device is registered, and an attempt to tty_[k]open() the chardev between these two steps will lead to tty->dev being assigned NULL by alloc_tty_struct().
This will be addressed in a second patch.
Fixes: 6a7e6f78c235 ("tty: close race between device register and open") Signed-off-by: Max Staudt max@enpas.org Cc: stable@vger.kernel.org --- drivers/tty/tty_io.c | 54 +++++++++++++++++++++++++------------------- 1 file changed, 31 insertions(+), 23 deletions(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index ca9b7d7bad2b..e922b84524d2 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -3245,6 +3245,7 @@ struct device *tty_register_device_attr(struct tty_driver *driver, struct ktermios *tp; struct device *dev; int retval; + bool cdev_added = false;
if (index >= driver->num) { pr_err("%s: Attempt to register invalid tty line number (%d)\n", @@ -3257,24 +3258,6 @@ struct device *tty_register_device_attr(struct tty_driver *driver, else tty_line_name(driver, index, name);
- dev = kzalloc(sizeof(*dev), GFP_KERNEL); - if (!dev) - return ERR_PTR(-ENOMEM); - - dev->devt = devt; - dev->class = &tty_class; - dev->parent = device; - dev->release = tty_device_create_release; - dev_set_name(dev, "%s", name); - dev->groups = attr_grp; - dev_set_drvdata(dev, drvdata); - - dev_set_uevent_suppress(dev, 1); - - retval = device_register(dev); - if (retval) - goto err_put; - if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) { /* * Free any saved termios data so that the termios state is @@ -3288,19 +3271,44 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
retval = tty_cdev_add(driver, devt, index, 1); if (retval) - goto err_del; + return ERR_PTR(retval); + + cdev_added = true; + } + + dev = kzalloc(sizeof(*dev), GFP_KERNEL); + if (!dev) { + retval = -ENOMEM; + goto err_del_cdev; }
- dev_set_uevent_suppress(dev, 0); - kobject_uevent(&dev->kobj, KOBJ_ADD); + dev->devt = devt; + dev->class = &tty_class; + dev->parent = device; + dev->release = tty_device_create_release; + dev_set_name(dev, "%s", name); + dev->groups = attr_grp; + dev_set_drvdata(dev, drvdata); + + retval = device_register(dev); + if (retval) + goto err_put;
return dev;
-err_del: - device_del(dev); err_put: + /* + * device_register() calls device_add(), after which + * we must use put_device() instead of kfree(). + */ put_device(dev);
+err_del_cdev: + if (cdev_added) { + cdev_del(driver->cdevs[index]); + driver->cdevs[index] = NULL; + } + return ERR_PTR(retval); } EXPORT_SYMBOL_GPL(tty_register_device_attr);
Since the chardev is now created before the class device is registered, an attempt to tty_[k]open() the chardev between these two steps will lead to tty->dev being assigned NULL by alloc_tty_struct().
alloc_tty_struct() is called via tty_init_dev() when the tty is firstly opened, and is entered with tty_mutex held, so let's lock the critical section in tty_register_device_attr() with the same global mutex. This guarantees that tty->dev can be assigned a sane value.
Fixes: 6a7e6f78c235 ("tty: close race between device register and open") Signed-off-by: Max Staudt max@enpas.org Cc: stable@vger.kernel.org --- drivers/tty/tty_io.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index e922b84524d2..94768509e2d2 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -3258,6 +3258,8 @@ struct device *tty_register_device_attr(struct tty_driver *driver, else tty_line_name(driver, index, name);
+ mutex_lock(&tty_mutex); + if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) { /* * Free any saved termios data so that the termios state is @@ -3271,7 +3273,7 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
retval = tty_cdev_add(driver, devt, index, 1); if (retval) - return ERR_PTR(retval); + goto err_unlock;
cdev_added = true; } @@ -3294,6 +3296,8 @@ struct device *tty_register_device_attr(struct tty_driver *driver, if (retval) goto err_put;
+ mutex_unlock(&tty_mutex); + return dev;
err_put: @@ -3309,6 +3313,9 @@ struct device *tty_register_device_attr(struct tty_driver *driver, driver->cdevs[index] = NULL; }
+err_unlock: + mutex_unlock(&tty_mutex); + return ERR_PTR(retval); } EXPORT_SYMBOL_GPL(tty_register_device_attr);
On Wed, 28 May 2025, Max Staudt wrote:
Since the chardev is now created before the class device is registered, an attempt to tty_[k]open() the chardev between these two steps will lead to tty->dev being assigned NULL by alloc_tty_struct().
alloc_tty_struct() is called via tty_init_dev() when the tty is firstly opened, and is entered with tty_mutex held, so let's lock the critical section in tty_register_device_attr() with the same global mutex. This guarantees that tty->dev can be assigned a sane value.
Fixes: 6a7e6f78c235 ("tty: close race between device register and open") Signed-off-by: Max Staudt max@enpas.org Cc: stable@vger.kernel.org
drivers/tty/tty_io.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index e922b84524d2..94768509e2d2 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -3258,6 +3258,8 @@ struct device *tty_register_device_attr(struct tty_driver *driver, else tty_line_name(driver, index, name);
- mutex_lock(&tty_mutex);
Use guard() so you don't need to change the returns and rollback path.
- if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) { /*
- Free any saved termios data so that the termios state is
@@ -3271,7 +3273,7 @@ struct device *tty_register_device_attr(struct tty_driver *driver, retval = tty_cdev_add(driver, devt, index, 1); if (retval)
return ERR_PTR(retval);
goto err_unlock;cdev_added = true; } @@ -3294,6 +3296,8 @@ struct device *tty_register_device_attr(struct tty_driver *driver, if (retval) goto err_put;
- mutex_unlock(&tty_mutex);
- return dev;
err_put: @@ -3309,6 +3313,9 @@ struct device *tty_register_device_attr(struct tty_driver *driver, driver->cdevs[index] = NULL; } +err_unlock:
- mutex_unlock(&tty_mutex);
- return ERR_PTR(retval);
} EXPORT_SYMBOL_GPL(tty_register_device_attr);
On 6/2/25 19:31, Ilpo Järvinen wrote:
- mutex_lock(&tty_mutex);
Use guard() so you don't need to change the returns and rollback path.
Thanks, I didn't know about this new kind of helper.
I'll leave it up to the TTY maintainers - if they don't express a preference for guard(), then I deem this code simple enough to leave it as-is, because I don't have any experience with guard(), and in fact, until 5 minutes ago, I didn't know at all that GCC cleanup attributes even exist.
Interestingly, Documentation/process/maintainer-netdev.rst documents a preference against guard(). I wonder why, but that's for another day.
Do you have an idea on how to solve the circular lock that the kernel test robot found for v1 of this patch?
https://lore.kernel.org/linux-serial/202505281412.8c836cb7-lkp@intel.com/
Max
On 02. 06. 25, 15:40, Max Staudt wrote:
On 6/2/25 19:31, Ilpo Järvinen wrote:
+ mutex_lock(&tty_mutex);
Use guard() so you don't need to change the returns and rollback path.
Thanks, I didn't know about this new kind of helper.
I'll leave it up to the TTY maintainers - if they don't express a preference for guard(),
I prefer guard(). Actually, I have a patchset to add a support for guard() for uart_lock and console_lock too and use it all over (incl. __free). They untangle the code on many places and get rid of much unneeded churn.
But in this very case, I see there is a label, I am not sure if it works right here. Try compiling with clang -- it will tell you. You likely won't cross the label with the guard().
thanks,
Hello,
kernel test robot noticed "WARNING:possible_circular_locking_dependency_detected" on:
commit: c3184e841ee2a1585b89e4bbd90cacb41063871f ("[PATCH v2 2/2] tty: Fix race against tty_open() in tty_register_device_attr()") url: https://github.com/intel-lab-lkp/linux/commits/Max-Staudt/tty-Fix-race-again... base: https://git.kernel.org/cgit/linux/kernel/git/gregkh/tty.git tty-testing patch link: https://lore.kernel.org/all/20250528132816.11433-2-max@enpas.org/ patch subject: [PATCH v2 2/2] tty: Fix race against tty_open() in tty_register_device_attr()
in testcase: boot
config: x86_64-randconfig-001-20250530 compiler: gcc-12 test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
(please refer to attached dmesg/kmsg for entire log/backtrace)
+-------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ | | 44db64e370 | c3184e841e | +-------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+ | WARNING:possible_circular_locking_dependency_detected | 0 | 6 | | WARNING:possible_circular_locking_dependency_detected_swapper_is_trying_to_acquire_lock:at:tty_port_open_but_task_is_already_holding_lock:at:tty_lock | 0 | 6 | +-------------------------------------------------------------------------------------------------------------------------------------------------------+------------+------------+
If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot oliver.sang@intel.com | Closes: https://lore.kernel.org/oe-lkp/202506031638.a5c78088-lkp@intel.com
[ 22.678060][ T1] WARNING: possible circular locking dependency detected [ 22.678860][ T1] 6.15.0-rc4-00108-gc3184e841ee2 #1 Tainted: G T [ 22.679596][ T1] ------------------------------------------------------ [ 22.680280][ T1] swapper/1 is trying to acquire lock: [ 22.680750][ T1] ffff888101cf02d0 (&port->mutex){+.+.}-{4:4}, at: tty_port_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/tty_port.c:761) [ 22.681597][ T1] [ 22.681597][ T1] but task is already holding lock: [ 22.682232][ T1] ffff8881084f91e0 (&tty->legacy_mutex){+.+.}-{4:4}, at: tty_lock (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/tty_mutex.c:19) [ 22.683067][ T1] [ 22.683067][ T1] which lock already depends on the new lock. [ 22.683067][ T1] [ 22.683981][ T1] [ 22.683981][ T1] the existing dependency chain (in reverse order) is: [ 22.684732][ T1] [ 22.684732][ T1] -> #2 (&tty->legacy_mutex){+.+.}-{4:4}: [ 22.685465][ T1] validate_chain (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:3286 kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:3909) [ 22.685990][ T1] __lock_acquire (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:5235) [ 22.688240][ T1] lock_acquire (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:472 kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:5868 kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:5823) [ 22.688677][ T1] __mutex_lock (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/mutex.c:603 kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/mutex.c:746) [ 22.689128][ T1] mutex_lock_nested (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/mutex.c:799) [ 22.689636][ T1] tty_lock (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/tty_mutex.c:19) [ 22.690065][ T1] tty_init_dev (kbuild/obj/consumer/x86_64-randconfig-001-20250530/include/linux/module.h:730) [ 22.690553][ T1] tty_init_dev (kbuild/obj/consumer/x86_64-randconfig-001-20250530/include/linux/module.h:730) [ 22.691065][ T1] tty_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/tty_io.c:2073 kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/tty_io.c:2120) [ 22.691582][ T1] chrdev_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/char_dev.c:414) [ 22.692010][ T1] do_dentry_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/open.c:956) [ 22.692506][ T1] vfs_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/open.c:1087) [ 22.692910][ T1] do_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/namei.c:3881) [ 22.693344][ T1] path_openat (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/namei.c:4039) [ 22.693796][ T1] do_filp_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/namei.c:4067) [ 22.694218][ T1] file_open_name (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/open.c:1374) [ 22.694669][ T1] filp_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/open.c:1394) [ 22.695063][ T1] console_on_rootfs (kbuild/obj/consumer/x86_64-randconfig-001-20250530/init/main.c:1528) [ 22.695624][ T1] kernel_init_freeable (kbuild/obj/consumer/x86_64-randconfig-001-20250530/init/main.c:1578) [ 22.696135][ T1] kernel_init (kbuild/obj/consumer/x86_64-randconfig-001-20250530/init/main.c:1459) [ 22.696554][ T1] ret_from_fork (kbuild/obj/consumer/x86_64-randconfig-001-20250530/arch/x86/kernel/process.c:159) [ 22.697060][ T1] ret_from_fork_asm (kbuild/obj/consumer/x86_64-randconfig-001-20250530/arch/x86/entry/entry_64.S:258) [ 22.697516][ T1] [ 22.697516][ T1] -> #1 (tty_mutex){+.+.}-{4:4}: [ 22.698166][ T1] validate_chain (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:3286 kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:3909) [ 22.698652][ T1] __lock_acquire (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:5235) [ 22.699158][ T1] lock_acquire (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:472 kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:5868 kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:5823) [ 22.699577][ T1] __mutex_lock (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/mutex.c:603 kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/mutex.c:746) [ 22.700113][ T1] mutex_lock_nested (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/mutex.c:799) [ 22.700564][ T1] tty_register_device_attr (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/tty_io.c:3250) [ 22.701135][ T1] tty_port_register_device_attr_serdev (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/tty_port.c:199) [ 22.701722][ T1] serial_core_add_one_port (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/serial/serial_core.c:3184) [ 22.702255][ T1] serial_core_register_port (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/serial/serial_core.c:3388) [ 22.702868][ T1] serial_ctrl_register_port (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/serial/serial_ctrl.c:42) [ 22.703443][ T1] uart_add_one_port (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/serial/serial_port.c:144) [ 22.703888][ T1] serial8250_register_8250_port (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/serial/8250/8250_core.c:822) [ 22.704473][ T1] serial_pnp_probe (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/serial/8250/8250_pnp.c:480) [ 22.704935][ T1] pnp_device_probe (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/pnp/driver.c:113) [ 22.705438][ T1] really_probe (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/base/dd.c:579 kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/base/dd.c:657) [ 22.705882][ T1] __driver_probe_device (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/base/dd.c:799) [ 22.706388][ T1] driver_probe_device (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/base/dd.c:829) [ 22.706886][ T1] __driver_attach (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/base/dd.c:1216 kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/base/dd.c:1155) [ 22.707345][ T1] bus_for_each_dev (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/base/bus.c:369) [ 22.707854][ T1] driver_attach (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/base/dd.c:1234) [ 22.708343][ T1] bus_add_driver (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/base/bus.c:678) [ 22.708788][ T1] driver_register (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/base/driver.c:249) [ 22.709313][ T1] pnp_register_driver (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/pnp/driver.c:281) [ 22.709779][ T1] serial8250_pnp_init (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/serial/8250/8250_pnp.c:531) [ 22.710314][ T1] serial8250_init (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/serial/8250/8250_platform.c:315) [ 22.710850][ T1] do_one_initcall (kbuild/obj/consumer/x86_64-randconfig-001-20250530/init/main.c:1257) [ 22.711331][ T1] do_initcalls (kbuild/obj/consumer/x86_64-randconfig-001-20250530/init/main.c:1318 kbuild/obj/consumer/x86_64-randconfig-001-20250530/init/main.c:1335) [ 22.711819][ T1] kernel_init_freeable (kbuild/obj/consumer/x86_64-randconfig-001-20250530/init/main.c:1569) [ 22.712320][ T1] kernel_init (kbuild/obj/consumer/x86_64-randconfig-001-20250530/init/main.c:1459) [ 22.712739][ T1] ret_from_fork (kbuild/obj/consumer/x86_64-randconfig-001-20250530/arch/x86/kernel/process.c:159) [ 22.713196][ T1] ret_from_fork_asm (kbuild/obj/consumer/x86_64-randconfig-001-20250530/arch/x86/entry/entry_64.S:258) [ 22.713650][ T1] [ 22.713650][ T1] -> #0 (&port->mutex){+.+.}-{4:4}: [ 22.714356][ T1] check_noncircular (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:2215) [ 22.714826][ T1] check_prev_add (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:3167) [ 22.715274][ T1] validate_chain (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:3286 kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:3909) [ 22.715793][ T1] __lock_acquire (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:5235) [ 22.716237][ T1] lock_acquire (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:472 kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:5868 kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/lockdep.c:5823) [ 22.716741][ T1] __mutex_lock (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/mutex.c:603 kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/mutex.c:746) [ 22.717172][ T1] mutex_lock_nested (kbuild/obj/consumer/x86_64-randconfig-001-20250530/kernel/locking/mutex.c:799) [ 22.717631][ T1] tty_port_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/tty_port.c:761) [ 22.718106][ T1] uart_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/serial/serial_core.c:1974) [ 22.718642][ T1] tty_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/drivers/tty/tty_io.c:2140) [ 22.719094][ T1] chrdev_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/char_dev.c:414) [ 22.719514][ T1] do_dentry_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/open.c:956) [ 22.719966][ T1] vfs_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/open.c:1087) [ 22.720411][ T1] do_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/namei.c:3881) [ 22.720873][ T1] path_openat (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/namei.c:4039) [ 22.721298][ T1] do_filp_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/namei.c:4067) [ 22.721848][ T1] file_open_name (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/open.c:1374) [ 22.722280][ T1] filp_open (kbuild/obj/consumer/x86_64-randconfig-001-20250530/fs/open.c:1394) [ 22.722739][ T1] console_on_rootfs (kbuild/obj/consumer/x86_64-randconfig-001-20250530/init/main.c:1528) [ 22.723194][ T1] kernel_init_freeable (kbuild/obj/consumer/x86_64-randconfig-001-20250530/init/main.c:1578) [ 22.723695][ T1] kernel_init (kbuild/obj/consumer/x86_64-randconfig-001-20250530/init/main.c:1459) [ 22.724200][ T1] ret_from_fork (kbuild/obj/consumer/x86_64-randconfig-001-20250530/arch/x86/kernel/process.c:159) [ 22.724709][ T1] ret_from_fork_asm (kbuild/obj/consumer/x86_64-randconfig-001-20250530/arch/x86/entry/entry_64.S:258) [ 22.725164][ T1] [ 22.725164][ T1] other info that might help us debug this: [ 22.725164][ T1] [ 22.726026][ T1] Chain exists of: [ 22.726026][ T1] &port->mutex --> tty_mutex --> &tty->legacy_mutex [ 22.726026][ T1]
The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20250603/202506031638.a5c78088-lkp@i...
linux-stable-mirror@lists.linaro.org
-
Ilpo Järvinen -
Jiri Slaby -
kernel test robot -
Max Staudt