lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <12dfd74a-2c01-441d-9085-c1a0ec45f908@roeck-us.net>
Date: Mon, 9 Dec 2024 07:41:33 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, Masahiro Yamada <masahiroy@...nel.org>,
	Fabio Estevam <festevam@...x.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Niklas Schnelle <schnelle@...ux.ibm.com>,
	Dave Penkler <dpenkler@...il.com>,
	Stafford Horne <shorne@...il.com>, Waiman Long <longman@...hat.com>
Subject: Re: Linux 6.13-rc2

On Sun, Dec 08, 2024 at 02:15:17PM -0800, Linus Torvalds wrote:
> The diffstat looks a bit unusual with 80%+ drivers, and a lot of it
> one-liners, but that's actually just because of a couple of automated
> scripts that got run after -rc1 for some cleanups. Nothing
> particularly interesting, but it makes for a lot of noise in the diff.
> 
> That said, there are real fixes in there too, but nothing that looks
> hugely remarkable. The shortlog below gives a flavor of it all. That's
> m ostly drivers too, but there's networking and bpf and some arch
> updates too.
> 
> Please do keep testing, and then we can all take it a bit easier over
> the holidays,
> 

Build results:
	total: 161 pass: 155 fail: 6
Failed builds:
	csky:allmodconfig
	i386:allyesconfig
	i386:allmodconfig
	openrisc:allmodconfig
	s390:allmodconfig
	xtensa:allmodconfig
Qemu test results:
	total: 544 pass: 528 fail: 16
Failed tests:
	arm:imx25-pdk:imx_v4_v5_defconfig:nonand:mem128:net=default:imx25-pdk:initrd
	arm:imx25-pdk:imx_v4_v5_defconfig:nonand:sd:mem128:net=default:imx25-pdk:ext2
	arm:imx25-pdk:imx_v4_v5_defconfig:nonand:usb0:mem128:net=default:imx25-pdk:ext2
	arm:imx25-pdk:imx_v4_v5_defconfig:nonand:usb1:mem128:net=default:imx25-pdk:ext2
	arm:mcimx6ul-evk:imx_v6_v7_defconfig:nodrm:mem256:net=nic:net=nic:imx6ul-14x14-evk:initrd
	arm:mcimx6ul-evk:imx_v6_v7_defconfig:nodrm:sd:mem256:net=nic:net=nic:imx6ul-14x14-evk:ext2
	arm:mcimx6ul-evk:imx_v6_v7_defconfig:nodrm:usb0:mem256:net=nic:net=nic:imx6ul-14x14-evk:ext2
	arm:mcimx6ul-evk:imx_v6_v7_defconfig:nodrm:usb1:mem256:net=nic:net=nic:imx6ul-14x14-evk:ext2
	arm:mcimx7d-sabre:imx_v6_v7_defconfig:nodrm:smp2:mem256:net=nic:imx7d-sdb:initrd
	arm:mcimx7d-sabre:imx_v6_v7_defconfig:nodrm:smp2:usb1:mem256:net=nic:imx7d-sdb:ext2
	arm:mcimx7d-sabre:imx_v6_v7_defconfig:nodrm:smp2:sd:mem256:net=nic:imx7d-sdb:ext2
	arm:sabrelite:imx_v6_v7_defconfig:nodrm:mem256:net=default:imx6dl-sabrelite:initrd
	arm:sabrelite:imx_v6_v7_defconfig:nodrm:mmc,b300:mem256:net=default:imx6dl-sabrelite:ext2
	arm:sabrelite:imx_v6_v7_defconfig:nodrm:usb0:mem256:net=default:imx6dl-sabrelite:ext2
	arm:sabrelite:imx_v6_v7_defconfig:nodrm:usb1:mem256:net=default:imx6dl-sabrelite:ext2
	openrisc:or1200:or1ksim_defconfig
Unit test results:
	pass: 464016 fail: 0

A couple of problems have been fixed since last week. Fixes for the
remaining issues seen in my tests have all been submitted. Most of those
patches are queued in linux-next. Here is a summary from my fixes branch
at git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git.

4ea915f32887 openrisc: place exception table at the head of vmlinux
5d481cfdbbca ARM: imx: Re-introduce the PINCTRL selection
62fb306f9082 locking/lockdep: Enforce PROVE_RAW_LOCK_NESTING only if ARCH_SUPPORTS_RT
e49fe26b045d tty: serial: Work around warning backtrace in serial8250_set_defaults
f11efcf05715 staging: gpib: Fix i386 build issue
1468f1923008 staging: gpib: Make GPIB_NI_PCI_ISA depend on HAS_IOPORT

All my build and boot tests pass with those patches applied.

I attached a long version of the commit log for reference and for details.
I added owners to Cc.

Guenter

---
commit 4ea915f3288756d829ba8abbd6cee10cf84a5a11
Author:     Masahiro Yamada <masahiroy@...nel.org>
AuthorDate: Mon Dec 2 15:28:22 2024 +0900
Commit:     Guenter Roeck <linux@...ck-us.net>
CommitDate: Sun Dec 8 15:41:42 2024 -0800

    openrisc: place exception table at the head of vmlinux
    
    Since commit 0043ecea2399 ("vmlinux.lds.h: Adjust symbol ordering in
    text output section"), the exception table in arch/openrisc/kernel/head.S
    is no longer positioned at the very beginning of the kernel image, which
    causes a boot failure.
    
    Currently, the exception table resides in the regular .text section.
    Previously, it was placed at the head by relying on the linker receiving
    arch/openrisc/kernel/head.o as the first object. However, this behavior
    has changed because sections like .text.{asan,unknown,unlikely,hot} now
    precede the regular .text section.
    
    The .head.text section is intended for entry points requiring special
    placement. However, in OpenRISC, this section has been misused: instead
    of the entry points, it contains boot code meant to be discarded after
    booting. This feature is typically handled by the .init.text section.
    
    This commit addresses the issue by replacing the current __HEAD marker
    with __INIT and re-annotating the entry points with __HEAD. Additionally,
    it adds __REF to entry.S to suppress the following modpost warning:
    
      WARNING: modpost: vmlinux: section mismatch in reference: _tng_kernel_start+0x70 (section: .text) -> _start (section: .init.text)
    
    Fixes: 0043ecea2399 ("vmlinux.lds.h: Adjust symbol ordering in text output section")
    Reported-by: Guenter Roeck <linux@...ck-us.net>
    Closes: https://lore.kernel.org/all/5e032233-5b65-4ad5-ac50-d2eb6c00171c@roeck-us.net/#t
    Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
    Link: https://lore.kernel.org/r/20241202062909.2194341-1-masahiroy@kernel.org
    Signed-off-by: Guenter Roeck <linux@...ck-us.net>

commit 5d481cfdbbca351f7fa347bd59f1471db7123305
Author:     Fabio Estevam <festevam@...x.de>
AuthorDate: Wed Nov 27 16:06:05 2024 -0300
Commit:     Guenter Roeck <linux@...ck-us.net>
CommitDate: Sun Dec 8 15:41:42 2024 -0800

    ARM: imx: Re-introduce the PINCTRL selection
    
    Since commit 17d210018914 ("ARM: imx: Allow user to disable pinctrl"),
    the CONFIG_PINCTRL option is no longer implicitly selected, causing
    several i.MX SoC pinctrl drivers no longer getting selected by default.
    
    This causes boot regressions on the ARMv4, ARMv5, ARMv6 and ARMv7
    i.MX SoCs.
    
    Fix it by selecting CONFIG_PINCTRL as before.
    
    This defeats the purpose of 7d210018914 ("ARM: imx: Allow user to disable
    pinctrl"), but it is the less invasive fix for the boot regressions.
    
    The attempt to build Layerscape without pinctrl can still be explored
    later as suggested by Arnd:
    
    "Overall, my best advice here is still to not change the way
    i.MX pinctrl works at all, but just fix Layerscape to not depend
    on i.MX. The reason for the 'select' here is clearly that the
    i.MX machines would fail to boot without pinctrl, and changing
    that because of Layerscape seems backwards."
    
    Fixes: 17d210018914 ("ARM: imx: Allow user to disable pinctrl")
    Reported-by: Guenter Roeck <linux@...ck-us.net>
    Closes: https://lore.kernel.org/linux-arm-kernel/49ff070a-ce67-42d7-84ec-8b54fd7e9742@roeck-us.net/
    Signed-off-by: Fabio Estevam <festevam@...x.de>
    Acked-by: Arnd Bergmann <arnd@...db.de>
    Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
    Tested-by: Guenter Roeck <linux@...ck-us.net>
    Link: https://lore.kernel.org/20241127190605.1367157-1-festevam@gmail.com
    Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
    Signed-off-by: Guenter Roeck <linux@...ck-us.net>

commit 62fb306f9082badff8e7ddc65140c156f380cb96
Author:     Waiman Long <longman@...hat.com>
AuthorDate: Wed Nov 27 21:00:09 2024 -0500
Commit:     Guenter Roeck <linux@...ck-us.net>
CommitDate: Sun Dec 8 15:41:42 2024 -0800

    locking/lockdep: Enforce PROVE_RAW_LOCK_NESTING only if ARCH_SUPPORTS_RT
    
    Relax the rule to set PROVE_RAW_LOCK_NESTING by default only for arches
    that supports PREEMPT_RT.  For arches that do not support PREEMPT_RT,
    they will not be forced to address unimportant raw lock nesting issues
    when they want to enable PROVE_LOCKING.  They do have the option
    to enable it to look for these raw locking nesting problems if they
    choose to.
    
    Suggested-by: Guenter Roeck <linux@...ck-us.net>
    Signed-off-by: Waiman Long <longman@...hat.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
    Tested-by: Guenter Roeck <linux@...ck-us.net>
    Link: https://lore.kernel.org/r/20241128020009.83347-1-longman@redhat.com
    Signed-off-by: Guenter Roeck <linux@...ck-us.net>

commit e49fe26b045d7819e45e0ed7156d9c546b0e5276
Author:     Guenter Roeck <linux@...ck-us.net>
AuthorDate: Thu Dec 5 06:30:33 2024 -0800
Commit:     Guenter Roeck <linux@...ck-us.net>
CommitDate: Sun Dec 8 15:41:42 2024 -0800

    tty: serial: Work around warning backtrace in serial8250_set_defaults
    
    Commit 7c7e6c8924e7 ("tty: serial: handle HAS_IOPORT dependencies")
    triggers warning backtraces on a number of platforms which don't support
    IO ports.
    
    WARNING: CPU: 0 PID: 0 at drivers/tty/serial/8250/8250_port.c:470 serial8250_set_defaults+0x148/0x1d8
    Unsupported UART type 0
    
    The problem is seen because serial8250_set_defaults() is called for
    all members of the serial8250_ports[] array even if that array is
    not initialized.
    
    Work around the problem by only displaying the warning if the port
    type is not 0 (UPIO_PORT) or if iobase is set for the port.
    
    Fixes: 7c7e6c8924e7 ("tty: serial: handle HAS_IOPORT dependencies")
    Acked-by: Arnd Bergmann <arnd@...db.de>
    Cc: Niklas Schnelle <schnelle@...ux.ibm.com>
    Signed-off-by: Guenter Roeck <linux@...ck-us.net>
    Tested-by: Stafford Horne <shorne@...il.com>
    Link: https://lore.kernel.org/r/20241205143033.2695333-1-linux@roeck-us.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
    Signed-off-by: Guenter Roeck <linux@...ck-us.net>

commit f11efcf05715a9f4df0411452cdebb832006798a
Author:     Dave Penkler <dpenkler@...il.com>
AuthorDate: Wed Dec 4 17:21:28 2024 +0100
Commit:     Guenter Roeck <linux@...ck-us.net>
CommitDate: Sun Dec 8 15:41:42 2024 -0800

    staging: gpib: Fix i386 build issue
    
    These drivers cast resource_type_t to void * causing the build to fail.
    
    With CONFIG_X86_PAE enabled the resource_size_t type is a 64bit unsigned
    int which cannot be cast to a 32 bit pointer.
    
    Disable these drivers if X68_PAE is enabled
    
    Reported-by: Guenter Roeck <linux@...ck-us.net>
    Closes: https://lore.kernel.org/all/f10e976e-7a04-4454-b38d-39cd18f142da@roeck-us.net/
    Fixes: e9dc69956d4d ("staging: gpib: Add Computer Boards GPIB driver")
    Fixes: e1339245eba3 ("staging: gpib: Add Computer Equipment Corporation GPIB driver")
    Fixes: bb1bd92fa0f2 ("staging: gpib: Add ines GPIB driver")
    Fixes: 0cd5b05551e0 ("staging: gpib: Add TNT4882 chip based GPIB driver")
    Signed-off-by: Dave Penkler <dpenkler@...il.com>
    Link: https://lore.kernel.org/r/20241204162128.25617-1-dpenkler@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
    Signed-off-by: Guenter Roeck <linux@...ck-us.net>

commit 1468f19230080ec3c5b6f8565e679c6482d650fb
Author:     Nathan Chancellor <nathan@...nel.org>
AuthorDate: Sat Nov 23 13:03:25 2024 -0700
Commit:     Guenter Roeck <linux@...ck-us.net>
CommitDate: Sun Dec 8 15:41:42 2024 -0800

    staging: gpib: Make GPIB_NI_PCI_ISA depend on HAS_IOPORT
    
    After commit 78ecb0375685 ("staging: gpib: make port I/O code
    conditional"), building tnt4882.ko on platforms without HAS_IOPORT (such
    as hexagon and s390) fails with:
    
      ERROR: modpost: "inb_wrapper" [drivers/staging/gpib/tnt4882/tnt4882.ko] undefined!
      ERROR: modpost: "inw_wrapper" [drivers/staging/gpib/tnt4882/tnt4882.ko] undefined!
      ERROR: modpost: "nec7210_locking_ioport_write_byte" [drivers/staging/gpib/tnt4882/tnt4882.ko] undefined!
      ERROR: modpost: "nec7210_locking_ioport_read_byte" [drivers/staging/gpib/tnt4882/tnt4882.ko] undefined!
      ERROR: modpost: "outb_wrapper" [drivers/staging/gpib/tnt4882/tnt4882.ko] undefined!
      ERROR: modpost: "outw_wrapper" [drivers/staging/gpib/tnt4882/tnt4882.ko] undefined!
    
    Only allow tnt4882.ko to be built when CONFIG_HAS_IOPORT is set to avoid
    this build failure, as this driver unconditionally needs it.
    
    Fixes: 78ecb0375685 ("staging: gpib: make port I/O code conditional")
    Signed-off-by: Nathan Chancellor <nathan@...nel.org>
    Tested-by: Geert Uytterhoeven <geert@...ux-m68k.org>
    Link: https://lore.kernel.org/r/20241123-gpib-tnt4882-depends-on-has_ioport-v1-1-033c58b64751@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
    Signed-off-by: Guenter Roeck <linux@...ck-us.net>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ