* Re: [PATCH] serial: 8250_pci: Don't specify conflicting values to pci_device_id members
From: Andy Shevchenko @ 2026-06-03 10:45 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Greg Kroah-Hartman, Jiri Slaby, Florian Eckert,
Martin Roukala (né Peres), Kees Cook, linux-kernel,
linux-serial
In-Reply-To: <20260603095616.937968-2-u.kleine-koenig@baylibre.com>
On Wed, Jun 03, 2026 at 11:56:16AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> The PCI_VDEVICE macro assigns 0 to .class and .class_mask to allow the
> next value in the initializer to define the value for .driver_data.
>
> So the construct
>
> {
> PCI_VDEVICE(INTASHIELD, 0x0D21),
> .class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
> .class_mask = 0xffff00,
> .driver_data = pbn_b2_4_115200,
> },
>
> introduced in commit 44e55f1f3088 ("serial: 8250_pci: Consistently
> define pci_device_ids using named initializers") has conflicting
> assignments. In only some configurations (i.e. W=1 for me) that makes
> the compiler unhappy.
>
> So convert the two affected items to PCI_DEVICE which doesn't have that
> hidden assigment to .class and .class_mask.
Reported-by? Closes?
> Fixes: 44e55f1f3088 ("serial: 8250_pci: Consistently define pci_device_ids using named initializers")
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
I will test it right away.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] serial: 8250_pci: Don't specify conflicting values to pci_device_id members
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-03 9:56 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Andy Shevchenko
Cc: Florian Eckert, Martin Roukala (né Peres), Kees Cook,
linux-kernel, linux-serial
The PCI_VDEVICE macro assigns 0 to .class and .class_mask to allow the
next value in the initializer to define the value for .driver_data.
So the construct
{
PCI_VDEVICE(INTASHIELD, 0x0D21),
.class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
.class_mask = 0xffff00,
.driver_data = pbn_b2_4_115200,
},
introduced in commit 44e55f1f3088 ("serial: 8250_pci: Consistently
define pci_device_ids using named initializers") has conflicting
assignments. In only some configurations (i.e. W=1 for me) that makes
the compiler unhappy.
So convert the two affected items to PCI_DEVICE which doesn't have that
hidden assigment to .class and .class_mask.
Fixes: 44e55f1f3088 ("serial: 8250_pci: Consistently define pci_device_ids using named initializers")
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/tty/serial/8250/8250_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 3e5bc9e8d269..58b4e525bdb6 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -5394,12 +5394,12 @@ static const struct pci_device_id serial_pci_tbl[] = {
* Brainboxes UC-260/271/701/756
*/
{
- PCI_VDEVICE(INTASHIELD, 0x0D21),
+ PCI_DEVICE(PCI_VENDOR_ID_INTASHIELD, 0x0D21),
.class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
.class_mask = 0xffff00,
.driver_data = pbn_b2_4_115200,
}, {
- PCI_VDEVICE(INTASHIELD, 0x0E34),
+ PCI_DEVICE(PCI_VENDOR_ID_INTASHIELD, 0x0E34),
.class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
.class_mask = 0xffff00,
.driver_data = pbn_b2_4_115200,
base-commit: 44e55f1f3088e4a471a943fbcf087ea7783a0199
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3] serial: 8250_pci: Consistently define pci_device_ids using named initializers
From: Andy Shevchenko @ 2026-06-03 9:53 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Greg Kroah-Hartman, Jiri Slaby, Markus Schneider-Pargmann,
linux-serial, linux-kernel
In-Reply-To: <ah_2rD9UPEYu78mv@monoceros>
On Wed, Jun 03, 2026 at 11:43:11AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> On Wed, Jun 03, 2026 at 09:24:34AM +0300, Andy Shevchenko wrote:
> > On Wed, Jun 03, 2026 at 08:12:38AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > On Tue, Jun 02, 2026 at 10:20:56PM +0200, Andy Shevchenko wrote:
> > > > This patch broke the build.
> > > >
> > > > drivers/tty/serial/8250/8250_pci.c:5398:12: error: initializer overrides prior initialization of this subobject [-Werror,-Winitializer-overrides]
> > > > 5398 | .class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
> > > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > include/linux/pci_ids.h:74:45: note: expanded from macro 'PCI_CLASS_COMMUNICATION_MULTISERIAL'
> > > > 74 | #define PCI_CLASS_COMMUNICATION_MULTISERIAL 0x0702
> > > >
> > > > and so on...
> > >
> > > Oh, it works fine for me with clang 19.1.7, gcc 11.3.0, gcc 12.4.0, gcc
> > > 13.3.0, gcc 14.2.0 and gcc 15.2.0, but I agree it's a bit obscure
> > > because .class and .class_mask are specified twice; once by PCI_VDEVICE
> > > and once explicitly.
> >
> > > Which compiler are you using that breaks here? I guess I might have
> > > broken more drivers this way, so it would be great to have a setup to
> > > reproduce your issue.
> >
> > My make command:
> >
> > make LLVM=-19 W=1 C=1 CF=-D__CHECK_ENDIAN__ ...
> >
> > The line the above error is from is from your patch.
>
> OK, I can reproduce with that cmdline, thanks. Expect a patch in a
> moment.
Thanks, will be glad to test ASAP.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3] serial: 8250_pci: Consistently define pci_device_ids using named initializers
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-03 9:43 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Greg Kroah-Hartman, Jiri Slaby, Markus Schneider-Pargmann,
linux-serial, linux-kernel
In-Reply-To: <ah_Iovpb8N2OTucV@ashevche-desk.local>
[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]
Hello Andy,
On Wed, Jun 03, 2026 at 09:24:34AM +0300, Andy Shevchenko wrote:
> On Wed, Jun 03, 2026 at 08:12:38AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > On Tue, Jun 02, 2026 at 10:20:56PM +0200, Andy Shevchenko wrote:
> > > This patch broke the build.
> > >
> > > drivers/tty/serial/8250/8250_pci.c:5398:12: error: initializer overrides prior initialization of this subobject [-Werror,-Winitializer-overrides]
> > > 5398 | .class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > include/linux/pci_ids.h:74:45: note: expanded from macro 'PCI_CLASS_COMMUNICATION_MULTISERIAL'
> > > 74 | #define PCI_CLASS_COMMUNICATION_MULTISERIAL 0x0702
> > >
> > > and so on...
> >
> > Oh, it works fine for me with clang 19.1.7, gcc 11.3.0, gcc 12.4.0, gcc
> > 13.3.0, gcc 14.2.0 and gcc 15.2.0, but I agree it's a bit obscure
> > because .class and .class_mask are specified twice; once by PCI_VDEVICE
> > and once explicitly.
>
> > Which compiler are you using that breaks here? I guess I might have
> > broken more drivers this way, so it would be great to have a setup to
> > reproduce your issue.
>
> My make command:
>
> make LLVM=-19 W=1 C=1 CF=-D__CHECK_ENDIAN__ ...
>
> The line the above error is from is from your patch.
OK, I can reproduce with that cmdline, thanks. Expect a patch in a
moment.
> > Once all the initializer are converted to named initialisation, we
> > should definitively drop the assignment to .class and .class_mask in
> > PCI_VDEVICE, but that doesn't work yet.
>
> Please, address the build issue first. I'm surprised the LKP hadn't complained
> on that (yet?). Note, that all redefinitions like this are broken and need to
> be addressed.
Full ack, I didn't want to say that dropping the assignments in
PCI_VDEVICE are the way to fix this issue, but only that it's a
surprising thing in it that should be fixed as soon as possible (i.e.
not now).
Thanks
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [tty:tty-testing] BUILD SUCCESS b586d69177b5fc92450a5f37a3bb1ce50aa87e39
From: kernel test robot @ 2026-06-03 8:09 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-serial
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tty-testing
branch HEAD: b586d69177b5fc92450a5f37a3bb1ce50aa87e39 Merge tag 'v7.1-rc6' into tty-next
elapsed time: 2056m
configs tested: 208
configs skipped: 13
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260602 gcc-11.5.0
arc randconfig-002-20260602 gcc-14.3.0
arm allnoconfig clang-23
arm allyesconfig gcc-15.2.0
arm defconfig clang-23
arm randconfig-001-20260602 gcc-11.5.0
arm randconfig-002-20260602 gcc-8.5.0
arm randconfig-003-20260602 gcc-10.5.0
arm randconfig-004-20260602 clang-23
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001 gcc-8.5.0
arm64 randconfig-001-20260602 gcc-14.3.0
arm64 randconfig-002 gcc-14.3.0
arm64 randconfig-002-20260602 gcc-15.2.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260602 clang-23
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260602 clang-23
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001 gcc-10.5.0
csky randconfig-001-20260602 gcc-12.5.0
csky randconfig-002 gcc-10.5.0
csky randconfig-002-20260602 gcc-14.3.0
hexagon allnoconfig clang-23
hexagon defconfig clang-23
hexagon randconfig-001 clang-17
hexagon randconfig-001-20260602 clang-23
hexagon randconfig-002 clang-23
hexagon randconfig-002-20260602 clang-23
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001 gcc-14
i386 buildonly-randconfig-001-20260602 clang-20
i386 buildonly-randconfig-002 clang-20
i386 buildonly-randconfig-002-20260602 gcc-13
i386 buildonly-randconfig-003 clang-20
i386 buildonly-randconfig-003-20260602 clang-20
i386 buildonly-randconfig-004 gcc-14
i386 buildonly-randconfig-004-20260602 gcc-14
i386 buildonly-randconfig-005 gcc-14
i386 buildonly-randconfig-005-20260602 clang-20
i386 buildonly-randconfig-006 gcc-14
i386 buildonly-randconfig-006-20260602 clang-20
i386 defconfig clang-20
i386 randconfig-001 clang-20
i386 randconfig-001-20260602 clang-20
i386 randconfig-001-20260603 gcc-14
i386 randconfig-002 gcc-14
i386 randconfig-002-20260602 clang-20
i386 randconfig-002-20260603 gcc-14
i386 randconfig-003 gcc-14
i386 randconfig-003-20260603 gcc-14
i386 randconfig-004 clang-20
i386 randconfig-004-20260602 clang-20
i386 randconfig-004-20260603 gcc-14
i386 randconfig-005 gcc-14
i386 randconfig-005-20260602 clang-20
i386 randconfig-005-20260603 clang-20
i386 randconfig-006 gcc-14
i386 randconfig-006-20260602 clang-20
i386 randconfig-006-20260603 gcc-12
i386 randconfig-007 gcc-14
i386 randconfig-007-20260602 gcc-14
i386 randconfig-007-20260603 clang-20
i386 randconfig-011-20260602 gcc-14
i386 randconfig-012-20260602 clang-20
i386 randconfig-013-20260602 clang-20
i386 randconfig-014-20260602 gcc-14
i386 randconfig-015-20260602 gcc-14
i386 randconfig-016-20260602 clang-20
i386 randconfig-017-20260602 gcc-14
loongarch allmodconfig clang-19
loongarch allnoconfig clang-23
loongarch defconfig clang-19
loongarch randconfig-001 clang-18
loongarch randconfig-001-20260602 clang-23
loongarch randconfig-002 gcc-13.4.0
loongarch randconfig-002-20260602 gcc-16.1.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig gcc-15.2.0
m68k defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260602 gcc-8.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260602 gcc-11.5.0
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig gcc-15.2.0
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001 gcc-13.4.0
parisc randconfig-001-20260602 gcc-12.5.0
parisc randconfig-002 gcc-8.5.0
parisc randconfig-002-20260602 gcc-8.5.0
parisc64 defconfig gcc-15.2.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig gcc-15.2.0
powerpc arches_defconfig gcc-15.2.0
powerpc randconfig-001 gcc-13.4.0
powerpc randconfig-001-20260602 clang-23
powerpc randconfig-002 gcc-10.5.0
powerpc randconfig-002-20260602 gcc-8.5.0
powerpc64 randconfig-001 clang-17
powerpc64 randconfig-001-20260602 clang-23
powerpc64 randconfig-002 clang-23
powerpc64 randconfig-002-20260602 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig clang-23
riscv randconfig-001-20260602 gcc-13.4.0
riscv randconfig-002-20260602 clang-23
s390 allmodconfig clang-18
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig clang-23
s390 randconfig-001-20260602 gcc-10.5.0
s390 randconfig-002-20260602 gcc-8.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig gcc-15.2.0
sh allyesconfig gcc-15.2.0
sh defconfig gcc-15.2.0
sh randconfig-001-20260602 gcc-11.5.0
sh randconfig-002-20260602 gcc-16.1.0
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260602 gcc-12.5.0
sparc randconfig-001-20260603 gcc-8.5.0
sparc randconfig-002-20260602 gcc-12.5.0
sparc randconfig-002-20260603 gcc-16.1.0
sparc64 allmodconfig clang-23
sparc64 defconfig clang-20
sparc64 randconfig-001-20260602 gcc-8.5.0
sparc64 randconfig-001-20260603 clang-23
sparc64 randconfig-002-20260602 clang-20
sparc64 randconfig-002-20260603 clang-20
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um defconfig clang-23
um i386_defconfig gcc-14
um randconfig-001-20260602 gcc-14
um randconfig-001-20260603 gcc-14
um randconfig-002-20260602 clang-23
um randconfig-002-20260603 gcc-14
um x86_64_defconfig clang-23
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260602 gcc-14
x86_64 buildonly-randconfig-002-20260602 clang-20
x86_64 buildonly-randconfig-003-20260602 gcc-14
x86_64 buildonly-randconfig-004-20260602 clang-20
x86_64 buildonly-randconfig-005-20260602 gcc-14
x86_64 buildonly-randconfig-006-20260602 gcc-14
x86_64 defconfig gcc-14
x86_64 randconfig-001-20260602 clang-20
x86_64 randconfig-002-20260602 clang-20
x86_64 randconfig-003-20260602 gcc-12
x86_64 randconfig-004-20260602 gcc-14
x86_64 randconfig-005-20260602 clang-20
x86_64 randconfig-006-20260602 clang-20
x86_64 randconfig-011 gcc-14
x86_64 randconfig-011-20260602 clang-20
x86_64 randconfig-012 gcc-14
x86_64 randconfig-012-20260602 clang-20
x86_64 randconfig-013 clang-20
x86_64 randconfig-013-20260602 clang-20
x86_64 randconfig-014 gcc-14
x86_64 randconfig-014-20260602 gcc-13
x86_64 randconfig-015 gcc-14
x86_64 randconfig-015-20260602 clang-20
x86_64 randconfig-016 clang-20
x86_64 randconfig-016-20260602 clang-20
x86_64 randconfig-071-20260602 clang-20
x86_64 randconfig-072-20260602 clang-20
x86_64 randconfig-073-20260602 gcc-14
x86_64 randconfig-074-20260602 gcc-14
x86_64 randconfig-075-20260602 clang-20
x86_64 randconfig-076-20260602 clang-20
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.2.0
xtensa randconfig-001-20260603 gcc-9.5.0
xtensa randconfig-002-20260602 gcc-14.3.0
xtensa randconfig-002-20260603 gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3] serial: 8250: Clear CON_PRINTBUFFER on port re-registration
From: Fushuai Wang @ 2026-06-03 6:56 UTC (permalink / raw)
To: fushuai.wang
Cc: alan, andy.shevchenko, gregkh, ilpo.jarvinen, jackzxcui1989,
jirislaby, kees, linux-kernel, linux-serial, osama.abdelkader,
sean, wangfushuai
In-Reply-To: <20260522101042.21976-1-fushuai.wang@linux.dev>
> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
> index a428e88938eb..5419f1d22d47 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -716,8 +716,12 @@ int serial8250_register_8250_port(const struct uart_8250_port *up)
> if (uart->port.type == PORT_8250_CIR)
> return -ENODEV;
>
> - if (uart->port.dev)
> + if (uart->port.dev) {
> + if (uart_console(&uart->port))
> + uart->port.cons->flags &= ~CON_PRINTBUFFER;
> +
> uart_remove_one_port(&serial8250_reg, &uart->port);
> + }
>
> uart->port.ctrl_id = up->port.ctrl_id;
> uart->port.port_id = up->port.port_id;
ping.
--
Regards,
WANG
^ permalink raw reply
* Re: [PATCH v3] serial: 8250_pci: Consistently define pci_device_ids using named initializers
From: Andy Shevchenko @ 2026-06-03 6:24 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Greg Kroah-Hartman, Jiri Slaby, Markus Schneider-Pargmann,
linux-serial, linux-kernel
In-Reply-To: <ah_DFCQH9e47qBp7@monoceros>
On Wed, Jun 03, 2026 at 08:12:38AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> On Tue, Jun 02, 2026 at 10:20:56PM +0200, Andy Shevchenko wrote:
> > On Tue, Apr 28, 2026 at 04:40:33PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > ... and PCI device helpers.
> > >
> > > The various struct pci_device_id were defined using a mixture of
> > > initialization by position and by name. Some use the PCI device helpers
> > > (like PCI_DEVICE and PCI_DEVICE_SUB) and others don't.
> > >
> > > Consistently use named initializers, drop assignments of 0 by position
> > > for .class and .class_mask and use the PCI device helpers. Also use
> > > consistent line-breaks and positioning for opening and closing curly
> > > braces.
> > >
> > > The secret plan is to make struct pci_device_id::driver_data an
> > > anonymous union (similar to
> > > https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/)
> > > and that requires named initializers. But it's also a nice cleanup on
> > > its own.
> > >
> > > This patch doesn't change the compiled result; this was verified using
> > > an allmodconfig with several things disabled that make reproducible
> > > builds harder on x86 and arm64.
> >
> > This patch broke the build.
> >
> > drivers/tty/serial/8250/8250_pci.c:5398:12: error: initializer overrides prior initialization of this subobject [-Werror,-Winitializer-overrides]
> > 5398 | .class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > include/linux/pci_ids.h:74:45: note: expanded from macro 'PCI_CLASS_COMMUNICATION_MULTISERIAL'
> > 74 | #define PCI_CLASS_COMMUNICATION_MULTISERIAL 0x0702
> >
> > and so on...
>
> Oh, it works fine for me with clang 19.1.7, gcc 11.3.0, gcc 12.4.0, gcc
> 13.3.0, gcc 14.2.0 and gcc 15.2.0, but I agree it's a bit obscure
> because .class and .class_mask are specified twice; once by PCI_VDEVICE
> and once explicitly.
> Which compiler are you using that breaks here? I guess I might have
> broken more drivers this way, so it would be great to have a setup to
> reproduce your issue.
My make command:
make LLVM=-19 W=1 C=1 CF=-D__CHECK_ENDIAN__ ...
The line the above error is from is from your patch.
> Once all the initializer are converted to named initialisation, we
> should definitively drop the assignment to .class and .class_mask in
> PCI_VDEVICE, but that doesn't work yet.
Please, address the build issue first. I'm surprised the LKP hadn't complained
on that (yet?). Note, that all redefinitions like this are broken and need to
be addressed.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3] serial: 8250_pci: Consistently define pci_device_ids using named initializers
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-03 6:12 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Greg Kroah-Hartman, Jiri Slaby, Markus Schneider-Pargmann,
linux-serial, linux-kernel
In-Reply-To: <ah87KOm0nfAyvr4c@black.igk.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]
On Tue, Jun 02, 2026 at 10:20:56PM +0200, Andy Shevchenko wrote:
> On Tue, Apr 28, 2026 at 04:40:33PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > ... and PCI device helpers.
> >
> > The various struct pci_device_id were defined using a mixture of
> > initialization by position and by name. Some use the PCI device helpers
> > (like PCI_DEVICE and PCI_DEVICE_SUB) and others don't.
> >
> > Consistently use named initializers, drop assignments of 0 by position
> > for .class and .class_mask and use the PCI device helpers. Also use
> > consistent line-breaks and positioning for opening and closing curly
> > braces.
> >
> > The secret plan is to make struct pci_device_id::driver_data an
> > anonymous union (similar to
> > https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/)
> > and that requires named initializers. But it's also a nice cleanup on
> > its own.
> >
> > This patch doesn't change the compiled result; this was verified using
> > an allmodconfig with several things disabled that make reproducible
> > builds harder on x86 and arm64.
>
> This patch broke the build.
>
> drivers/tty/serial/8250/8250_pci.c:5398:12: error: initializer overrides prior initialization of this subobject [-Werror,-Winitializer-overrides]
> 5398 | .class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/linux/pci_ids.h:74:45: note: expanded from macro 'PCI_CLASS_COMMUNICATION_MULTISERIAL'
> 74 | #define PCI_CLASS_COMMUNICATION_MULTISERIAL 0x0702
>
> and so on...
Oh, it works fine for me with clang 19.1.7, gcc 11.3.0, gcc 12.4.0, gcc
13.3.0, gcc 14.2.0 and gcc 15.2.0, but I agree it's a bit obscure
because .class and .class_mask are specified twice; once by PCI_VDEVICE
and once explicitly.
Which compiler are you using that breaks here? I guess I might have
broken more drivers this way, so it would be great to have a setup to
reproduce your issue.
Once all the initializer are converted to named initialisation, we
should definitively drop the assignment to .class and .class_mask in
PCI_VDEVICE, but that doesn't work yet.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] tty: vt: hold tty reference for keyboard callbacks
From: Jiri Slaby @ 2026-06-03 6:12 UTC (permalink / raw)
To: Morduan Zang, Greg Kroah-Hartman
Cc: linux-kernel, linux-serial, syzkaller-bugs,
syzbot+2932e8970a6398db95c3, Zhan Jun
In-Reply-To: <5186FF3C10B2F8A0+20260602061539.1500845-1-zhangdandan@uniontech.com>
On 02. 06. 26, 8:15, Morduan Zang wrote:
> From: Zhan Jun <zhanjun@uniontech.com>
>
> syzbot reported a use-after-free in stop_tty() when the VT
> keyboard path handles the hold key.
>
> The keyboard event path reads vc->port.tty under kbd_event_lock,
> but con_shutdown() clears the pointer under console_lock and the tty
> can be released after the final close. The keyboard lock therefore
> does not protect the tty lifetime.
>
> Let the VT port own a tty reference by using tty_port_tty_set() when
> installing and shutting down the console tty. Use tty_port_tty_get()
> in the keyboard paths before dereferencing vc->port.tty and drop the
> reference after the last use.
>
> Reported-by: syzbot+2932e8970a6398db95c3@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/6a1dde0d.bd48a97d.14881d.0005.GAE@google.com/
> Signed-off-by: Zhan Jun <zhanjun@uniontech.com>
> ---
> drivers/tty/vt/keyboard.c | 17 ++++++++++++-----
> drivers/tty/vt/vt.c | 4 ++--
> 2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index dfdea0842149..19f8df9706ee 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -509,9 +509,13 @@ static void fn_show_ptregs(struct vc_data *vc)
>
> static void fn_hold(struct vc_data *vc)
> {
> - struct tty_struct *tty = vc->port.tty;
> + struct tty_struct *tty;
> +
> + if (rep)
> + return;
>
> - if (rep || !tty)
> + tty = tty_port_tty_get(&vc->port);
We have guards (tty_port_tty) and you should use those.
thanks,
--
js
suse labs
^ permalink raw reply
* [PATCH 3/3] serial: mxs-auart: fix IRQ registration ordering and manage console clock
From: Rosen Penev @ 2026-06-03 2:58 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260603025857.287148-1-rosenp@gmail.com>
Move the main UART IRQ registration after uart_add_one_port so that
s->port.state and s->port.lock are initialized before the interrupt
handler can run. Mask all UART interrupts before adding the port to
prevent spurious IRQs left by the bootloader.
After probe succeeds, disable the module clock for non-console ports
since startup will re-enable it on port open. For console ports, keep
the clock prepared so auart_console_write() can safely call
clk_enable() from atomic context.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/tty/serial/mxs-auart.c | 39 ++++++++++++++++++++++++++--------
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 4499e3206e85..d40d82f112c0 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1603,10 +1603,6 @@ static int mxs_auart_probe(struct platform_device *pdev)
}
s->port.irq = irq;
- ret = devm_request_irq(&pdev->dev, irq, mxs_auart_irq_handle, 0,
- dev_name(&pdev->dev), s);
- if (ret)
- goto out_disable_clk;
platform_set_drvdata(pdev, s);
@@ -1627,9 +1623,28 @@ static int mxs_auart_probe(struct platform_device *pdev)
mxs_auart_reset_deassert(s);
+ /* Mask all UART interrupts to prevent spurious IRQs from bootloader */
+ mxs_write(0, s, REG_INTR);
+
ret = uart_add_one_port(&auart_driver, &s->port);
- if (ret)
- goto out_free_qpio_irq;
+ if (ret) {
+ auart_port[s->port.line] = NULL;
+ goto out_disable_clk;
+ }
+
+ /*
+ * Request the main IRQ after uart_add_one_port so that
+ * s->port.state and s->port.lock are initialized before
+ * the handler can run in response to a bootloader-left
+ * interrupt.
+ */
+ ret = devm_request_irq(&pdev->dev, irq, mxs_auart_irq_handle, 0,
+ dev_name(&pdev->dev), s);
+ if (ret) {
+ uart_remove_one_port(&auart_driver, &s->port);
+ auart_port[s->port.line] = NULL;
+ goto out_disable_clk;
+ }
/* ASM9260 don't have version reg */
if (is_asm9260_auart(s)) {
@@ -1641,10 +1656,16 @@ static int mxs_auart_probe(struct platform_device *pdev)
(version >> 16) & 0xff, version & 0xffff);
}
- return 0;
+ /*
+ * Disable clock - startup will re-enable when the port is opened.
+ * For the console port the clock must stay prepared so that
+ * auart_console_write() can safely call clk_enable() from
+ * atomic context.
+ */
+ if (!uart_console(&s->port))
+ clk_disable_unprepare(s->clk);
-out_free_qpio_irq:
- auart_port[s->port.line] = NULL;
+ return 0;
out_disable_clk:
clk_disable_unprepare(s->clk);
--
2.54.0
^ permalink raw reply related
* [PATCH 2/3] serial: mxs-auart: use devm resources for iomem and GPIO IRQs
From: Rosen Penev @ 2026-06-03 2:58 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260603025857.287148-1-rosenp@gmail.com>
Replace platform_get_resource + ioremap with
devm_platform_get_and_ioremap_resource and convert GPIO IRQ
request_irq/free_irq to devm_request_irq. This eliminates the
mxs_auart_free_gpio_irq function and its call sites, and the
out_iounmap error label. Simplify the remove function accordingly.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/tty/serial/mxs-auart.c | 55 ++++++++--------------------------
1 file changed, 12 insertions(+), 43 deletions(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 1390fa000a5b..4499e3206e85 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1517,15 +1517,6 @@ static int mxs_auart_init_gpios(struct mxs_auart_port *s, struct device *dev)
return 0;
}
-static void mxs_auart_free_gpio_irq(struct mxs_auart_port *s)
-{
- enum mctrl_gpio_idx i;
-
- for (i = 0; i < UART_GPIO_MAX; i++)
- if (s->gpio_irq[i] >= 0)
- free_irq(s->gpio_irq[i], s);
-}
-
static int mxs_auart_request_gpio_irq(struct mxs_auart_port *s)
{
int *irq = s->gpio_irq;
@@ -1537,21 +1528,13 @@ static int mxs_auart_request_gpio_irq(struct mxs_auart_port *s)
continue;
irq_set_status_flags(irq[i], IRQ_NOAUTOEN);
- err = request_irq(irq[i], mxs_auart_irq_handle,
- IRQ_TYPE_EDGE_BOTH, dev_name(s->dev), s);
+ err = devm_request_irq(s->dev, irq[i], mxs_auart_irq_handle,
+ IRQ_TYPE_EDGE_BOTH, dev_name(s->dev), s);
if (err)
dev_err(s->dev, "%s - Can't get %d irq\n",
__func__, irq[i]);
}
- /*
- * If something went wrong, rollback.
- * Be careful: i may be unsigned.
- */
- while (err && (i-- > 0))
- if (irq[i] >= 0)
- free_irq(irq[i], s);
-
return err;
}
@@ -1586,7 +1569,7 @@ static int mxs_auart_probe(struct platform_device *pdev)
return -EINVAL;
}
- s->devtype = (enum mxs_auart_type)of_device_get_match_data(&pdev->dev);
+ s->devtype = (unsigned long)of_device_get_match_data(&pdev->dev);
ret = mxs_get_clks(s, pdev);
if (ret)
@@ -1596,18 +1579,12 @@ static int mxs_auart_probe(struct platform_device *pdev)
if (ret)
return ret;
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!r) {
- ret = -ENXIO;
+ s->port.membase = devm_platform_get_and_ioremap_resource(pdev, 0, &r);
+ if (IS_ERR(s->port.membase)) {
+ ret = PTR_ERR(s->port.membase);
goto out_disable_clk;
}
-
s->port.mapbase = r->start;
- s->port.membase = ioremap(r->start, resource_size(r));
- if (!s->port.membase) {
- ret = -ENOMEM;
- goto out_disable_clk;
- }
s->port.ops = &mxs_auart_ops;
s->port.iotype = UPIO_MEM;
s->port.fifosize = MXS_AUART_FIFO_SIZE;
@@ -1622,21 +1599,21 @@ static int mxs_auart_probe(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
ret = irq;
- goto out_iounmap;
+ goto out_disable_clk;
}
s->port.irq = irq;
ret = devm_request_irq(&pdev->dev, irq, mxs_auart_irq_handle, 0,
dev_name(&pdev->dev), s);
if (ret)
- goto out_iounmap;
+ goto out_disable_clk;
platform_set_drvdata(pdev, s);
ret = mxs_auart_init_gpios(s, &pdev->dev);
if (ret) {
dev_err(&pdev->dev, "Failed to initialize GPIOs.\n");
- goto out_iounmap;
+ goto out_disable_clk;
}
/*
@@ -1644,7 +1621,7 @@ static int mxs_auart_probe(struct platform_device *pdev)
*/
ret = mxs_auart_request_gpio_irq(s);
if (ret)
- goto out_iounmap;
+ goto out_disable_clk;
auart_port[s->port.line] = s;
@@ -1667,11 +1644,7 @@ static int mxs_auart_probe(struct platform_device *pdev)
return 0;
out_free_qpio_irq:
- mxs_auart_free_gpio_irq(s);
- auart_port[pdev->id] = NULL;
-
-out_iounmap:
- iounmap(s->port.membase);
+ auart_port[s->port.line] = NULL;
out_disable_clk:
clk_disable_unprepare(s->clk);
@@ -1683,11 +1656,7 @@ static void mxs_auart_remove(struct platform_device *pdev)
struct mxs_auart_port *s = platform_get_drvdata(pdev);
uart_remove_one_port(&auart_driver, &s->port);
- auart_port[pdev->id] = NULL;
- mxs_auart_free_gpio_irq(s);
- iounmap(s->port.membase);
- if (is_asm9260_auart(s))
- clk_disable_unprepare(s->clk);
+ auart_port[s->port.line] = NULL;
}
static struct platform_driver mxs_auart_driver = {
--
2.54.0
^ permalink raw reply related
* [PATCH 1/3] serial: mxs-auart: rework clock handling in mxs_get_clks and probe
From: Rosen Penev @ 2026-06-03 2:58 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20260603025857.287148-1-rosenp@gmail.com>
Use devm_clk_get_enabled for the AHB clock so its enable/disable
lifetime is managed by the driver model. Move the mod clock
(clk) prepare_enable out of mxs_get_clks and into probe so that
clk_set_rate is called while the clock is still disabled, avoiding
CLK_SET_RATE_GATE failures. Clean up the error labels accordingly.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/tty/serial/mxs-auart.c | 47 ++++++++++++----------------------
1 file changed, 17 insertions(+), 30 deletions(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 697318dbb146..1390fa000a5b 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1470,34 +1470,22 @@ static int mxs_get_clks(struct mxs_auart_port *s,
return PTR_ERR(s->clk);
}
- s->clk_ahb = devm_clk_get(s->dev, "ahb");
+ s->clk_ahb = devm_clk_get_enabled(s->dev, "ahb");
if (IS_ERR(s->clk_ahb)) {
dev_err(s->dev, "Failed to get \"ahb\" clk\n");
return PTR_ERR(s->clk_ahb);
}
- err = clk_prepare_enable(s->clk_ahb);
- if (err) {
- dev_err(s->dev, "Failed to enable ahb_clk!\n");
- return err;
- }
-
+ /*
+ * Set mod clock rate while it is still disabled so
+ * CLK_SET_RATE_GATE does not cause clk_set_rate to fail.
+ * The mod clock will be enabled in mxs_auart_startup()
+ * and in probe after mxs_get_clks returns.
+ */
err = clk_set_rate(s->clk, clk_get_rate(s->clk_ahb));
- if (err) {
+ if (err)
dev_err(s->dev, "Failed to set rate!\n");
- goto disable_clk_ahb;
- }
- err = clk_prepare_enable(s->clk);
- if (err) {
- dev_err(s->dev, "Failed to enable clk!\n");
- goto disable_clk_ahb;
- }
-
- return 0;
-
-disable_clk_ahb:
- clk_disable_unprepare(s->clk_ahb);
return err;
}
@@ -1604,17 +1592,21 @@ static int mxs_auart_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = clk_prepare_enable(s->clk);
+ if (ret)
+ return ret;
+
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r) {
ret = -ENXIO;
- goto out_disable_clks;
+ goto out_disable_clk;
}
s->port.mapbase = r->start;
s->port.membase = ioremap(r->start, resource_size(r));
if (!s->port.membase) {
ret = -ENOMEM;
- goto out_disable_clks;
+ goto out_disable_clk;
}
s->port.ops = &mxs_auart_ops;
s->port.iotype = UPIO_MEM;
@@ -1681,11 +1673,8 @@ static int mxs_auart_probe(struct platform_device *pdev)
out_iounmap:
iounmap(s->port.membase);
-out_disable_clks:
- if (is_asm9260_auart(s)) {
- clk_disable_unprepare(s->clk);
- clk_disable_unprepare(s->clk_ahb);
- }
+out_disable_clk:
+ clk_disable_unprepare(s->clk);
return ret;
}
@@ -1697,10 +1686,8 @@ static void mxs_auart_remove(struct platform_device *pdev)
auart_port[pdev->id] = NULL;
mxs_auart_free_gpio_irq(s);
iounmap(s->port.membase);
- if (is_asm9260_auart(s)) {
+ if (is_asm9260_auart(s))
clk_disable_unprepare(s->clk);
- clk_disable_unprepare(s->clk_ahb);
- }
}
static struct platform_driver mxs_auart_driver = {
--
2.54.0
^ permalink raw reply related
* [PATCH 0/3] serial: mxs-auart: devm conversion, clock rework, and IRQ ordering fixes
From: Rosen Penev @ 2026-06-03 2:58 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Jiri Slaby, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:TTY LAYER AND SERIAL DRIVERS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
This series cleans up the mxs-auart driver by converting to devm-managed
resources, fixing clock prepare/enable ordering, and addressing IRQ
registration races.
Patch 1 reworks the clock handling to use devm_clk_get_enabled and
reorders clk_prepare_enable after clk_set_rate to avoid
CLK_SET_RATE_GATE failures.
Patch 2 converts iomem mapping and GPIO IRQ requests to devm,
removing the manual cleanup paths.
Patch 3 moves the main UART IRQ registration after uart_add_one_port
so the port state is initialized before the handler can run, and
manages the module clock for console vs non-console ports correctly.
Rosen Penev (3):
serial: mxs-auart: rework clock handling in mxs_get_clks and probe
serial: mxs-auart: use devm resources for iomem and GPIO IRQs
serial: mxs-auart: fix IRQ registration ordering and manage console
clock
drivers/tty/serial/mxs-auart.c | 133 ++++++++++++++-------------------
1 file changed, 55 insertions(+), 78 deletions(-)
--
2.54.0
^ permalink raw reply
* [syzbot] Monthly serial report (Jun 2026)
From: syzbot @ 2026-06-02 20:32 UTC (permalink / raw)
To: gregkh, linux-kernel, linux-serial, syzkaller-bugs
Hello serial maintainers/developers,
This is a 31-day syzbot report for the serial subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/serial
During the period, 1 new issues were detected and 0 were fixed.
In total, 16 issues are still open and 48 have already been fixed.
There are also 3 low-priority issues.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 196 No possible deadlock in kbd_event
https://syzkaller.appspot.com/bug?extid=781c8bb5e4d62cc883d3
<2> 62 No KMSAN: uninit-value in n_tty_lookahead_flow_ctrl (2)
https://syzkaller.appspot.com/bug?extid=290abdcd4f509377a0eb
<3> 10 No KASAN: slab-use-after-free Read in kbd_event (2)
https://syzkaller.appspot.com/bug?extid=098cefc0911c68db5dab
<4> 3701 Yes KMSAN: uninit-value in n_tty_receive_buf_standard
https://syzkaller.appspot.com/bug?extid=559c7fe4b8bac56d38c2
<5> 359 Yes KMSAN: uninit-value in n_tty_receive_buf_closing (3)
https://syzkaller.appspot.com/bug?extid=dd514b5f0cf048aec256
<6> 137 Yes possible deadlock in tty_buffer_flush (3)
https://syzkaller.appspot.com/bug?extid=52cf91760dcb1dac6376
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: [PATCH v3] serial: 8250_pci: Consistently define pci_device_ids using named initializers
From: Andy Shevchenko @ 2026-06-02 20:20 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Greg Kroah-Hartman, Jiri Slaby, Markus Schneider-Pargmann,
linux-serial, linux-kernel
In-Reply-To: <20260428144033.1037617-2-u.kleine-koenig@baylibre.com>
On Tue, Apr 28, 2026 at 04:40:33PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> ... and PCI device helpers.
>
> The various struct pci_device_id were defined using a mixture of
> initialization by position and by name. Some use the PCI device helpers
> (like PCI_DEVICE and PCI_DEVICE_SUB) and others don't.
>
> Consistently use named initializers, drop assignments of 0 by position
> for .class and .class_mask and use the PCI device helpers. Also use
> consistent line-breaks and positioning for opening and closing curly
> braces.
>
> The secret plan is to make struct pci_device_id::driver_data an
> anonymous union (similar to
> https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/)
> and that requires named initializers. But it's also a nice cleanup on
> its own.
>
> This patch doesn't change the compiled result; this was verified using
> an allmodconfig with several things disabled that make reproducible
> builds harder on x86 and arm64.
This patch broke the build.
drivers/tty/serial/8250/8250_pci.c:5398:12: error: initializer overrides prior initialization of this subobject [-Werror,-Winitializer-overrides]
5398 | .class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/pci_ids.h:74:45: note: expanded from macro 'PCI_CLASS_COMMUNICATION_MULTISERIAL'
74 | #define PCI_CLASS_COMMUNICATION_MULTISERIAL 0x0702
and so on...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v5] serial: 8250_omap: clear rx_running on zero-length DMA completes
From: andriy.shevchenko @ 2026-06-02 18:37 UTC (permalink / raw)
To: Matthias Feser
Cc: Moteen Shah, linux-serial@vger.kernel.org,
gregkh@linuxfoundation.org, jirislaby@kernel.org,
linux-kernel@vger.kernel.org, k-willis@ti.com, msp@baylibre.com
In-Reply-To: <BE3P281MB55155F2F5795E411F5A65282EE0B2@BE3P281MB5515.DEUP281.PROD.OUTLOOK.COM>
On Tue, May 26, 2026 at 07:35:09AM +0000, Matthias Feser wrote:
> On AM33xx RX DMA only triggers when the FIFO reaches the
> configured threshold (typically 48 bytes). For smaller bursts
> no DMA request is issued and the FIFO is drained by RX timeout.
>
> In this case __dma_rx_do_complete() can legitimately see count == 0.
>
> The current code exits early in this case and does not clear
> dma->rx_running, leaving the DMA state inconsistent. This can
> prevent RX DMA from restarting and may cause
> omap_8250_rx_dma_flush() to fail, marking DMA as broken.
>
> Fix this by clearing dma->rx_running once the DMA transfer has
> completed or been terminated, even if no data was transferred.
...
> + dma->rx_running = 0;
> if (!count)
> goto out;
> ret = tty_insert_flip_string(tty_port, dma->rx_buf, count);
>
> - dma->rx_running = 0;
I'm wondering if this opens a window when dma->rx_buf may be rewritten (or
unmapped or something else) before tty layer has a chance to insert bytes to
its ring buffer. I.o.w. is this change synchronous to other threads?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] serial: max310x: implement gpio_chip::get_direction()
From: Bartosz Golaszewski @ 2026-06-02 16:18 UTC (permalink / raw)
To: Tapio Reijonen
Cc: linux-kernel, linux-serial, linux-gpio, Greg Kroah-Hartman,
Jiri Slaby, Linus Walleij, Bartosz Golaszewski, Alexander Shiyan
In-Reply-To: <20260602-b4-serial-max310x-gpio-get-direction-v1-1-23bf84e8ee14@vaisala.com>
On Tue, 2 Jun 2026 12:02:35 +0200, Tapio Reijonen
<tapio.reijonen@vaisala.com> said:
> It's strongly recommended for GPIO drivers to always implement the
> .get_direction() callback - even when the direction is tracked in
> software. The GPIO core emits a warning when the callback is missing
> and a user reads the direction of a line, e.g. via
> /sys/kernel/debug/gpio.
>
> The MAX310X keeps the GPIO direction in the GPIOCFG register (a set bit
> selects output), which the existing direction_input/output callbacks
> already program, so the current direction can be read back directly.
>
> Fixes: f65444187a66 ("serial: New serial driver MAX310X")
> Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
> ---
> Found and HW-tested on an i.MX6 SoloX board with a MAX14830 over SPI:
> without this, "cat /sys/kernel/debug/gpio" triggers the gpiolib.c:429
> WARNING (tainting the kernel W) on each queried MAX14830 line; with it
> applied the lines report their in/out direction and the WARNING is gone.
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 01/11] params: bound array element output to the caller's page buffer
From: David Laight @ 2026-06-02 13:04 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Kees Cook, Luis Chamberlain, Pengpeng Hou, stable, Petr Pavlu,
Richard Weinberger, Anton Ivanov, Johannes Berg,
Rafael J. Wysocki, Len Brown, Corey Minyard, Gabriel Somlo,
Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Simona Vetter, Bart Van Assche,
Jason Gunthorpe, Leon Romanovsky, Laurent Pinchart, Hans de Goede,
Mauro Carvalho Chehab, Bjorn Helgaas, Hannes Reinecke,
James E.J. Bottomley, Martin K. Petersen, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Greg Kroah-Hartman, Jiri Slaby,
Alan Stern, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Jason Baron, Jim Cromie, Tiwei Bie, Benjamin Berg,
Ilpo Järvinen, David E. Box, Maciej W. Rozycki,
Srinivas Pandruvada, Peter Zijlstra, Heiko Carstens,
Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Georgia Garcia, kvm, dmaengine, linux-modules,
kasan-dev, linux-mm, apparmor, linux-security-module, linux-um,
linux-acpi, openipmi-developer, qemu-devel, intel-gfx, dri-devel,
linux-rdma, linux-media, linux-pci, linux-scsi, linux-pm,
linuxppc-dev, linux-serial, linux-usb, usb-storage,
virtualization, linux-kernel, linux-arch, netdev, linux-fsdevel,
linux-hardening
In-Reply-To: <ah699hwLxIIOZ0-7@ashevche-desk.local>
On Tue, 2 Jun 2026 14:26:46 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Thu, May 21, 2026 at 06:33:14AM -0700, Kees Cook wrote:
> >
> > param_array_get() appends each element's string representation into the
> > shared sysfs page buffer by passing buffer + off to the element getter.
> >
> > That works for getters that only write a small bounded string, but
> > param_get_charp() and similar helpers format against PAGE_SIZE from the
> > pointer they receive. Once off is non-zero, an element getter can
> > therefore write past the end of the original sysfs page buffer.
> >
> > Collect each element into a temporary PAGE_SIZE buffer first and then
> > copy only the remaining space into the caller's page buffer.
>
> ...
>
> > + elem_buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
>
> get_free_page() (or how it is called)?
The kmalloc() should be faster and I think has to be aligned.
There is another patch set to replace get_free_pages() with kmalloc().
Although all these 'show' functions should really head to using a safer
interface.
Although, at the moment, it is really difficult to find the ones that
are guaranteed to be passed a page aligned buffer.
-- David
>
> > + if (!elem_buf)
> > + return -ENOMEM;
> > +
> > for (i = off = 0; i < (arr->num ? *arr->num : arr->max); i++) {
> > - /* Replace \n with comma */
> > - if (i)
> > - buffer[off - 1] = ',';
> > p.arg = arr->elem + arr->elemsize * i;
> > check_kparam_locked(p.mod);
> > - ret = arr->ops->get(buffer + off, &p);
> > + ret = arr->ops->get(elem_buf, &p);
> > if (ret < 0)
> > - return ret;
> > + goto out;
> > + ret = min(ret, (int)(PAGE_SIZE - 1 - off));
>
> It's usually discouraged to use castings in min/max/clamp. Can we make ret long
> or do something different here?
>
> > + if (!ret)
> > + break;
>
> > + /* Replace the previous element's trailing newline with a comma. */
> > + if (i)
> > + buffer[off - 1] = ',';
>
> Can't we do this after with help of strreplace()?
>
> > + memcpy(buffer + off, elem_buf, ret);
> > off += ret;
> > + if (off == PAGE_SIZE - 1)
> > + break;
> > }
> > buffer[off] = '\0';
> > - return off;
> > + ret = off;
> > +out:
> > + kfree(elem_buf);
> > + return ret;
>
^ permalink raw reply
* Re: [PATCH 01/11] params: bound array element output to the caller's page buffer
From: Jason Gunthorpe @ 2026-06-02 12:33 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Kees Cook, Luis Chamberlain, Pengpeng Hou, stable, Petr Pavlu,
Richard Weinberger, Anton Ivanov, Johannes Berg,
Rafael J. Wysocki, Len Brown, Corey Minyard, Gabriel Somlo,
Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Simona Vetter, Bart Van Assche,
Leon Romanovsky, Laurent Pinchart, Hans de Goede,
Mauro Carvalho Chehab, Bjorn Helgaas, Hannes Reinecke,
James E.J. Bottomley, Martin K. Petersen, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Greg Kroah-Hartman, Jiri Slaby,
Alan Stern, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Jason Baron, Jim Cromie, Tiwei Bie, Benjamin Berg,
Ilpo Järvinen, David E. Box, Maciej W. Rozycki,
Srinivas Pandruvada, Peter Zijlstra, Heiko Carstens,
Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Georgia Garcia, kvm, dmaengine, linux-modules,
kasan-dev, linux-mm, apparmor, linux-security-module, linux-um,
linux-acpi, openipmi-developer, qemu-devel, intel-gfx, dri-devel,
linux-rdma, linux-media, linux-pci, linux-scsi, linux-pm,
linuxppc-dev, linux-serial, linux-usb, usb-storage,
virtualization, linux-kernel, linux-arch, netdev, linux-fsdevel,
linux-hardening
In-Reply-To: <ah699hwLxIIOZ0-7@ashevche-desk.local>
On Tue, Jun 02, 2026 at 02:26:46PM +0300, Andy Shevchenko wrote:
> On Thu, May 21, 2026 at 06:33:14AM -0700, Kees Cook wrote:
> >
> > param_array_get() appends each element's string representation into the
> > shared sysfs page buffer by passing buffer + off to the element getter.
> >
> > That works for getters that only write a small bounded string, but
> > param_get_charp() and similar helpers format against PAGE_SIZE from the
> > pointer they receive. Once off is non-zero, an element getter can
> > therefore write past the end of the original sysfs page buffer.
> >
> > Collect each element into a temporary PAGE_SIZE buffer first and then
> > copy only the remaining space into the caller's page buffer.
>
> ...
>
> > + elem_buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
>
> get_free_page() (or how it is called)?
I thought modern mm guidance was to use kmalloc whenever possible and
not use get_free_page() unless you intend to use the struct page bits?
Jason
^ permalink raw reply
* Re: [PATCH 01/11] params: bound array element output to the caller's page buffer
From: Andy Shevchenko @ 2026-06-02 11:26 UTC (permalink / raw)
To: Kees Cook
Cc: Luis Chamberlain, Pengpeng Hou, stable, Petr Pavlu,
Richard Weinberger, Anton Ivanov, Johannes Berg,
Rafael J. Wysocki, Len Brown, Corey Minyard, Gabriel Somlo,
Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Simona Vetter, Bart Van Assche,
Jason Gunthorpe, Leon Romanovsky, Laurent Pinchart, Hans de Goede,
Mauro Carvalho Chehab, Bjorn Helgaas, Hannes Reinecke,
James E.J. Bottomley, Martin K. Petersen, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Greg Kroah-Hartman, Jiri Slaby,
Alan Stern, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Jason Baron, Jim Cromie, Tiwei Bie, Benjamin Berg,
Ilpo Järvinen, David E. Box, Maciej W. Rozycki,
Srinivas Pandruvada, Peter Zijlstra, Heiko Carstens,
Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Georgia Garcia, kvm, dmaengine, linux-modules,
kasan-dev, linux-mm, apparmor, linux-security-module, linux-um,
linux-acpi, openipmi-developer, qemu-devel, intel-gfx, dri-devel,
linux-rdma, linux-media, linux-pci, linux-scsi, linux-pm,
linuxppc-dev, linux-serial, linux-usb, usb-storage,
virtualization, linux-kernel, linux-arch, netdev, linux-fsdevel,
linux-hardening
In-Reply-To: <20260521133326.2465264-1-kees@kernel.org>
On Thu, May 21, 2026 at 06:33:14AM -0700, Kees Cook wrote:
>
> param_array_get() appends each element's string representation into the
> shared sysfs page buffer by passing buffer + off to the element getter.
>
> That works for getters that only write a small bounded string, but
> param_get_charp() and similar helpers format against PAGE_SIZE from the
> pointer they receive. Once off is non-zero, an element getter can
> therefore write past the end of the original sysfs page buffer.
>
> Collect each element into a temporary PAGE_SIZE buffer first and then
> copy only the remaining space into the caller's page buffer.
...
> + elem_buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
get_free_page() (or how it is called)?
> + if (!elem_buf)
> + return -ENOMEM;
> +
> for (i = off = 0; i < (arr->num ? *arr->num : arr->max); i++) {
> - /* Replace \n with comma */
> - if (i)
> - buffer[off - 1] = ',';
> p.arg = arr->elem + arr->elemsize * i;
> check_kparam_locked(p.mod);
> - ret = arr->ops->get(buffer + off, &p);
> + ret = arr->ops->get(elem_buf, &p);
> if (ret < 0)
> - return ret;
> + goto out;
> + ret = min(ret, (int)(PAGE_SIZE - 1 - off));
It's usually discouraged to use castings in min/max/clamp. Can we make ret long
or do something different here?
> + if (!ret)
> + break;
> + /* Replace the previous element's trailing newline with a comma. */
> + if (i)
> + buffer[off - 1] = ',';
Can't we do this after with help of strreplace()?
> + memcpy(buffer + off, elem_buf, ret);
> off += ret;
> + if (off == PAGE_SIZE - 1)
> + break;
> }
> buffer[off] = '\0';
> - return off;
> + ret = off;
> +out:
> + kfree(elem_buf);
> + return ret;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] serial: max310x: implement gpio_chip::get_direction()
From: Tapio Reijonen @ 2026-06-02 10:02 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Linus Walleij,
Bartosz Golaszewski, Alexander Shiyan
Cc: linux-kernel, linux-serial, linux-gpio, Tapio Reijonen
It's strongly recommended for GPIO drivers to always implement the
.get_direction() callback - even when the direction is tracked in
software. The GPIO core emits a warning when the callback is missing
and a user reads the direction of a line, e.g. via
/sys/kernel/debug/gpio.
The MAX310X keeps the GPIO direction in the GPIOCFG register (a set bit
selects output), which the existing direction_input/output callbacks
already program, so the current direction can be read back directly.
Fixes: f65444187a66 ("serial: New serial driver MAX310X")
Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
---
Found and HW-tested on an i.MX6 SoloX board with a MAX14830 over SPI:
without this, "cat /sys/kernel/debug/gpio" triggers the gpiolib.c:429
WARNING (tainting the kernel W) on each queried MAX14830 line; with it
applied the lines report their in/out direction and the WARNING is gone.
---
drivers/tty/serial/max310x.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index ac7d3f197c3a5ce3531d5607f48e21a807314021..96df54a90b009d1b547f7a639b0b9a4281daf073 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -1212,6 +1212,18 @@ static int max310x_gpio_set(struct gpio_chip *chip, unsigned int offset,
return 0;
}
+static int max310x_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+ struct max310x_port *s = gpiochip_get_data(chip);
+ struct uart_port *port = &s->p[offset / 4].port;
+ unsigned int val;
+
+ val = max310x_port_read(port, MAX310X_GPIOCFG_REG);
+
+ return (val & (1 << (offset % 4))) ? GPIO_LINE_DIRECTION_OUT
+ : GPIO_LINE_DIRECTION_IN;
+}
+
static int max310x_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
{
struct max310x_port *s = gpiochip_get_data(chip);
@@ -1421,6 +1433,7 @@ static int max310x_probe(struct device *dev, const struct max310x_devtype *devty
s->gpio.owner = THIS_MODULE;
s->gpio.parent = dev;
s->gpio.label = devtype->name;
+ s->gpio.get_direction = max310x_gpio_get_direction;
s->gpio.direction_input = max310x_gpio_direction_input;
s->gpio.get = max310x_gpio_get;
s->gpio.direction_output= max310x_gpio_direction_output;
---
base-commit: e7ae89a0c97ce2b68b0983cd01eda67cf373517d
change-id: 20260602-b4-serial-max310x-gpio-get-direction-b10ee5be4f24
Best regards,
--
Tapio Reijonen <tapio.reijonen@vaisala.com>
^ permalink raw reply related
* [PATCH] tty: vt: hold tty reference for keyboard callbacks
From: Morduan Zang @ 2026-06-02 6:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, linux-serial, syzkaller-bugs,
syzbot+2932e8970a6398db95c3, Zhan Jun
From: Zhan Jun <zhanjun@uniontech.com>
syzbot reported a use-after-free in stop_tty() when the VT
keyboard path handles the hold key.
The keyboard event path reads vc->port.tty under kbd_event_lock,
but con_shutdown() clears the pointer under console_lock and the tty
can be released after the final close. The keyboard lock therefore
does not protect the tty lifetime.
Let the VT port own a tty reference by using tty_port_tty_set() when
installing and shutting down the console tty. Use tty_port_tty_get()
in the keyboard paths before dereferencing vc->port.tty and drop the
reference after the last use.
Reported-by: syzbot+2932e8970a6398db95c3@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/6a1dde0d.bd48a97d.14881d.0005.GAE@google.com/
Signed-off-by: Zhan Jun <zhanjun@uniontech.com>
---
drivers/tty/vt/keyboard.c | 17 ++++++++++++-----
drivers/tty/vt/vt.c | 4 ++--
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index dfdea0842149..19f8df9706ee 100644
--- a/drivers/tty/vt/keyboard.c
+++ b/drivers/tty/vt/keyboard.c
@@ -509,9 +509,13 @@ static void fn_show_ptregs(struct vc_data *vc)
static void fn_hold(struct vc_data *vc)
{
- struct tty_struct *tty = vc->port.tty;
+ struct tty_struct *tty;
+
+ if (rep)
+ return;
- if (rep || !tty)
+ tty = tty_port_tty_get(&vc->port);
+ if (!tty)
return;
/*
@@ -523,6 +527,8 @@ static void fn_hold(struct vc_data *vc)
start_tty(tty);
else
stop_tty(tty);
+
+ tty_kref_put(tty);
}
static void fn_num(struct vc_data *vc)
@@ -1431,9 +1437,8 @@ static void kbd_keycode(unsigned int keycode, int down, bool hw_raw)
struct keyboard_notifier_param param = { .vc = vc, .value = keycode, .down = down };
int rc;
- tty = vc->port.tty;
-
- if (tty && (!tty->driver_data)) {
+ tty = tty_port_tty_get(&vc->port);
+ if (tty && !tty->driver_data) {
/* No driver data? Strange. Okay we fix it then. */
tty->driver_data = vc;
}
@@ -1486,6 +1491,7 @@ static void kbd_keycode(unsigned int keycode, int down, bool hw_raw)
if (rep &&
(!vc_kbd_mode(kbd, VC_REPEAT) ||
(tty && !L_ECHO(tty) && tty_chars_in_buffer(tty)))) {
+ tty_kref_put(tty);
/*
* Don't repeat a key if the input buffers are not empty and the
* characters get aren't echoed locally. This makes key repeat
@@ -1493,6 +1499,7 @@ static void kbd_keycode(unsigned int keycode, int down, bool hw_raw)
*/
return;
}
+ tty_kref_put(tty);
param.shift = shift_final = (shift_state | kbd->slockstate) ^ kbd->lockstate;
param.ledstate = kbd->ledflagstate;
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index e99636ab9db5..ae191a1eaa05 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3755,7 +3755,7 @@ static int con_install(struct tty_driver *driver, struct tty_struct *tty)
return ret;
tty->driver_data = vc;
- vc->port.tty = tty;
+ tty_port_tty_set(&vc->port, tty);
tty_port_get(&vc->port);
if (!tty->winsize.ws_row && !tty->winsize.ws_col) {
@@ -3788,7 +3788,7 @@ static void con_shutdown(struct tty_struct *tty)
BUG_ON(vc == NULL);
guard(console_lock)();
- vc->port.tty = NULL;
+ tty_port_tty_set(&vc->port, NULL);
}
static void con_cleanup(struct tty_struct *tty)
--
2.50.1
^ permalink raw reply related
* Re: [PATCH 01/11] params: bound array element output to the caller's page buffer
From: Matthew Wilcox @ 2026-06-01 20:23 UTC (permalink / raw)
To: David Laight
Cc: Kees Cook, Luis Chamberlain, Pengpeng Hou, stable, Petr Pavlu,
Richard Weinberger, Anton Ivanov, Johannes Berg,
Rafael J. Wysocki, Len Brown, Corey Minyard, Gabriel Somlo,
Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, David Airlie, Simona Vetter, Bart Van Assche,
Jason Gunthorpe, Leon Romanovsky, Laurent Pinchart, Hans de Goede,
Mauro Carvalho Chehab, Bjorn Helgaas, Hannes Reinecke,
James E.J. Bottomley, Martin K. Petersen, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Greg Kroah-Hartman, Jiri Slaby,
Alan Stern, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Jason Baron, Jim Cromie, Tiwei Bie, Benjamin Berg,
Ilpo Järvinen, David E. Box, Maciej W. Rozycki,
Srinivas Pandruvada, Peter Zijlstra, Heiko Carstens,
Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <20260521174631.71a06440@pumpkin>
On Thu, May 21, 2026 at 05:46:31PM +0100, David Laight wrote:
> On Thu, 21 May 2026 06:33:14 -0700
> Kees Cook <kees@kernel.org> wrote:
> > Collect each element into a temporary PAGE_SIZE buffer first and then
> > copy only the remaining space into the caller's page buffer.
>
> Should this be using a 4k buffer on all architectures?
> Initially perhaps just using a different name for the constant until
> all the associated PAGE_SIZE limits have been removed.
If we're acually going to think about this, even 4KiB is too big.
An 80x25 terminal is 2000 bytes (assuming no utf8), so 4KiB is two
entire screenfuls. Limiting to 2048 would seem reasonable to me.
^ permalink raw reply
* Re: [PATCH 00/11] Convert moduleparams to seq_buf
From: Kees Cook @ 2026-06-01 19:59 UTC (permalink / raw)
To: Petr Pavlu
Cc: Luis Chamberlain, Pengpeng Hou, Richard Weinberger, Anton Ivanov,
Johannes Berg, Rafael J. Wysocki, Len Brown, Corey Minyard,
Gabriel Somlo, Michael S. Tsirkin, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, David Airlie, Simona Vetter,
Bart Van Assche, Jason Gunthorpe, Leon Romanovsky,
Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Bjorn Helgaas, Hannes Reinecke, James E.J. Bottomley,
Martin K. Petersen, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Greg Kroah-Hartman, Jiri Slaby, Alan Stern, Jason Wang, Xuan Zhuo,
Eugenio Pérez, Jason Baron, Jim Cromie, Tiwei Bie,
Benjamin Berg, Ilpo Järvinen, David E. Box,
Maciej W. Rozycki, Srinivas Pandruvada, Peter Zijlstra,
Heiko Carstens, Vasily Gorbik, Sean Christopherson, Paolo Bonzini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Vinod Koul, Frank Li, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Alexander Potapenko, Marco Elver, Dmitry Vyukov,
Andrew Morton, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andy Shevchenko, Georgia Garcia, kvm, dmaengine,
linux-modules, kasan-dev, linux-mm, apparmor,
linux-security-module, linux-um, linux-acpi, openipmi-developer,
qemu-devel, intel-gfx, dri-devel, linux-rdma, linux-media,
linux-pci, linux-scsi, linux-pm, linuxppc-dev, linux-serial,
linux-usb, usb-storage, virtualization, linux-kernel, linux-arch,
netdev, linux-fsdevel, linux-hardening
In-Reply-To: <88c5ca1d-eeda-4023-bc7a-397b92780db9@suse.com>
On Tue, May 26, 2026 at 08:53:06AM +0200, Petr Pavlu wrote:
> On 5/21/26 3:33 PM, Kees Cook wrote:
> > Hi,
> >
> > I tried to trim the CC list here, but it's still pretty huge...
> >
> > We've had a long-standing issue with "write to a string pointer" callbacks
> > that don't bounds check the destination (and for which the bounds is
> > also not part of the callback prototype, even if it is "known" to be
> > PAGE_SIZE, which sysfs_emit() depends on). Both moduleparams and sysfs
> > use this pattern. As a first step, and to test the migration method,
> > migrate moduleparams first.
> >
> > There are 2 "mechanical" treewide patches that are handled by Coccinelle:
> > - treewide: Convert struct kernel_param_ops initializers to DEFINE_KERNEL_PARAM_OPS
> > - treewide: Convert custom kernel_param_ops .get callbacks to seq_buf via cocci
> >
> > The last treewide patch is manual, and may need to be broken up into
> > per-subsystem patches, though I'd prefer to avoid this, as it would
> > extend the migration from 1 relase to at least 2 releases. (1 to
> > release the migration infrastructure, then 1 release to collect all the
> > subsystem changes, and possibly 1 more release to remove the migration
> > infrastructure.)
> >
> > Thoughts, questions?
>
> This looks reasonable to me. I added a few minor comments on the patches
> but they already look solid.
Thanks for the review! I'll get a v2 prepared with your notes addressed. :)
-Kees
--
Kees Cook
^ permalink raw reply
* [syzbot] [serial?] KASAN: slab-use-after-free Read in stop_tty
From: syzbot @ 2026-06-01 19:31 UTC (permalink / raw)
To: gregkh, jirislaby, linux-kernel, linux-serial, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: eb3f4b7426cf Merge tag 'nfsd-7.1-2' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=110a02b6580000
kernel config: https://syzkaller.appspot.com/x/.config?x=bd38685893011045
dashboard link: https://syzkaller.appspot.com/bug?extid=2932e8970a6398db95c3
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3e8630fd2e70/disk-eb3f4b74.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/3a23f2a3eb2a/vmlinux-eb3f4b74.xz
kernel image: https://storage.googleapis.com/syzbot-assets/e102c22c34c3/bzImage-eb3f4b74.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+2932e8970a6398db95c3@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-use-after-free in stop_t[ 93.746644][ T5837] BUG: KASAN: slab-use-after-free in __stop_tty drivers/tty/tty_io.c:742 [inline]
BUG: KASAN: slab-use-after-free in stop_t[ 93.746644][ T5837] BUG: KASAN: slab-use-after-free in stop_tty+0x115/0x140 drivers/tty/tty_io.c:766
Read of size 1 at addr ffff888037076480 by task syz.1.2/5837
CPU: 1 UID: 0 PID: 5837 Comm: syz.1.2 Not tainted syzkaller #0 PREEMPT_{RT,(full)}
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description+0x55/0x1e0 mm/kasan/report.c:378
print_report+0x58/0x70 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
__stop_tty drivers/tty/tty_io.c:742 [inline]
stop_tty+0x115/0x140 drivers/tty/tty_io.c:766
kbd_keycode drivers/tty/vt/keyboard.c:1565 [inline]
kbd_event+0x2f91/0x42f0 drivers/tty/vt/keyboard.c:1583
input_handle_events_default+0xd4/0x1a0 drivers/input/input.c:2558
input_pass_values+0x288/0x890 drivers/input/input.c:128
input_event_dispose+0x330/0x6b0 drivers/input/input.c:342
input_inject_event+0x1d7/0x320 drivers/input/input.c:424
evdev_write+0x328/0x4c0 drivers/input/evdev.c:528
vfs_write+0x2a3/0xba0 fs/read_write.c:686
ksys_write+0x156/0x270 fs/read_write.c:740
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fdc7927ce59
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fdc7748c028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fdc794f6180 RCX: 00007fdc7927ce59
RDX: 0000000000002250 RSI: 0000200000000040 RDI: 0000000000000008
RBP: 00007fdc79312d6f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fdc794f6218 R14: 00007fdc794f6180 R15: 00007fff3e71db88
</TASK>
Allocated by task 5835:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__kmalloc_cache_noprof+0x3a6/0x690 mm/slub.c:5420
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
alloc_tty_struct+0xa6/0x7b0 drivers/tty/tty_io.c:3102
tty_init_dev+0x59/0x4d0 drivers/tty/tty_io.c:1400
tty_open_by_driver drivers/tty/tty_io.c:2073 [inline]
tty_open+0x86e/0xd80 drivers/tty/tty_io.c:2120
chrdev_open+0x4d0/0x5f0 fs/char_dev.c:411
do_dentry_open+0x83d/0x13e0 fs/open.c:947
vfs_open+0x3b/0x350 fs/open.c:1079
do_open fs/namei.c:4699 [inline]
path_openat+0x2e43/0x38a0 fs/namei.c:4858
do_file_open+0x23e/0x4a0 fs/namei.c:4887
do_sys_openat2+0x113/0x200 fs/open.c:1364
do_sys_open fs/open.c:1370 [inline]
__do_sys_openat fs/open.c:1386 [inline]
__se_sys_openat fs/open.c:1381 [inline]
__x64_sys_openat+0x138/0x170 fs/open.c:1381
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 5800:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2689 [inline]
slab_free mm/slub.c:6251 [inline]
kfree+0x1c5/0x6c0 mm/slub.c:6566
process_one_work kernel/workqueue.c:3314 [inline]
process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3397
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3478
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Last potentially related work creation:
kasan_save_stack+0x3e/0x60 mm/kasan/common.c:57
kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:556
insert_work+0x3d/0x330 kernel/workqueue.c:2226
__queue_work+0xd1d/0x1090 kernel/workqueue.c:2393
queue_work_on+0x106/0x1d0 kernel/workqueue.c:2444
tty_release_struct+0xb8/0xd0 drivers/tty/tty_io.c:1692
tty_release+0xcb6/0x1710 drivers/tty/tty_io.c:1852
__fput+0x461/0xa70 fs/file_table.c:510
task_work_run+0x1d9/0x270 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0x193/0x680 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline]
do_syscall_64+0x353/0x580 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff888037076000
which belongs to the cache kmalloc-cg-2k of size 2048
The buggy address is located 1152 bytes inside of
freed 2048-byte region [ffff888037076000, ffff888037076800)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37070
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff888037070811
flags: 0x80000000000040(head|node=0|zone=1)
page_type: f5(slab)
raw: 0080000000000040 ffff88813fe263c0 dead000000000100 dead000000000122
raw: 0000000000000000 0000100000080008 00000000f5000000 ffff888037070811
head: 0080000000000040 ffff88813fe263c0 dead000000000100 dead000000000122
head: 0000000000000000 0000100000080008 00000000f5000000 ffff888037070811
head: 0080000000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff
head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5805, tgid 5803 (syz.0.1), ts 93327144778, free_ts 93319793659
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x22d/0x280 mm/page_alloc.c:1853
prep_new_page mm/page_alloc.c:1861 [inline]
get_page_from_freelist+0x28b2/0x2930 mm/page_alloc.c:3941
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5221
alloc_slab_page mm/slub.c:3278 [inline]
allocate_slab+0x77/0x660 mm/slub.c:3467
new_slab mm/slub.c:3525 [inline]
refill_objects+0x33c/0x3d0 mm/slub.c:7272
refill_sheaf mm/slub.c:2816 [inline]
__pcs_replace_empty_main+0x373/0x720 mm/slub.c:4652
alloc_from_pcs mm/slub.c:4750 [inline]
slab_alloc_node mm/slub.c:4884 [inline]
__do_kmalloc_node mm/slub.c:5295 [inline]
__kmalloc_node_track_caller_noprof+0x60b/0x7e0 mm/slub.c:5408
kmemdup_noprof+0x2b/0x70 mm/util.c:138
kmemdup_noprof include/linux/fortify-string.h:763 [inline]
neigh_sysctl_register+0xae/0xa90 net/core/neighbour.c:3861
addrconf_sysctl_register+0xb3/0x1c0 net/ipv6/addrconf.c:7379
ipv6_add_dev+0xd64/0x1400 net/ipv6/addrconf.c:460
addrconf_notify+0x771/0x1050 net/ipv6/addrconf.c:3662
notifier_call_chain+0x1ad/0x3d0 kernel/notifier.c:85
call_netdevice_notifiers_extack net/core/dev.c:2287 [inline]
call_netdevice_notifiers net/core/dev.c:2301 [inline]
register_netdevice+0x18d5/0x1ed0 net/core/dev.c:11461
nsim_init_netdevsim drivers/net/netdevsim/netdev.c:1069 [inline]
nsim_create+0xbff/0x1170 drivers/net/netdevsim/netdev.c:1151
__nsim_dev_port_add+0x857/0xd30 drivers/net/netdevsim/dev.c:1509
page last free pid 5805 tgid 5803 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1397 [inline]
__free_frozen_pages+0xfe5/0x10d0 mm/page_alloc.c:2938
__slab_free+0x252/0x2a0 mm/slub.c:5613
qlink_free mm/kasan/quarantine.c:163 [inline]
qlist_free_all+0x99/0x100 mm/kasan/quarantine.c:179
kasan_quarantine_reduce+0x148/0x160 mm/kasan/quarantine.c:286
__kasan_slab_alloc+0x22/0x80 mm/kasan/common.c:350
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4570 [inline]
slab_alloc_node mm/slub.c:4899 [inline]
__kmalloc_cache_noprof+0x338/0x690 mm/slub.c:5415
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
kset_create lib/kobject.c:965 [inline]
kset_create_and_add+0x5a/0x180 lib/kobject.c:1008
register_queue_kobjects net/core/net-sysfs.c:2091 [inline]
netdev_register_kobject+0x1a2/0x310 net/core/net-sysfs.c:2347
register_netdevice+0x146d/0x1ed0 net/core/dev.c:11423
nsim_init_netdevsim drivers/net/netdevsim/netdev.c:1069 [inline]
nsim_create+0xbff/0x1170 drivers/net/netdevsim/netdev.c:1151
__nsim_dev_port_add+0x857/0xd30 drivers/net/netdevsim/dev.c:1509
nsim_dev_port_add_all+0x37/0xf0 drivers/net/netdevsim/dev.c:1570
nsim_dev_reload_create drivers/net/netdevsim/dev.c:1622 [inline]
nsim_dev_reload_up+0x45f/0x7c0 drivers/net/netdevsim/dev.c:1058
devlink_reload+0x501/0x8d0 net/devlink/dev.c:475
devlink_nl_reload_doit+0xaaa/0xc80 net/devlink/dev.c:585
genl_family_rcv_msg_doit+0x22a/0x330 net/netlink/genetlink.c:1114
Memory state around the buggy address:
ffff888037076380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888037076400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888037076480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888037076500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888037076580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox