You all know the drill: it's Sunday afternoon, the two weeks of merge
window are over, and now we're supposed to start calming things down.
This isn't actually shaping up to be a particularly large release: we
"only" have 11.5k non-merge commits during this merge window, compared
to 13.5k last time around. So not exactly tiny, but smaller than the
last few releases. At least in number of commits.
That said, we've got a few core things that have been brewing for a
long time, most notably the multi-gen LRU VM series, and the initial
Rust scaffolding (no actual real Rust code in the kernel yet, but the
infrastructure is there).
And hey, this merge window was full of surprises for other reasons too
- my main machine was basically out of action for a couple of days
because it suddenly started showing memory problems, and it took me a
couple of days to get that sorted out (to a large degree because it
was unexpected and I started out blaming a kernel bug for the memory
corruption). All sorted out now, but it caused some frustration.
Talking about frustration, let me just say that after I got my machine
sorted out and caught up with the merge window, I wass somewhat
frustrated with various late pull requests. I've mentioned this
before, but it's _really_ quite annoying to get quite a few pull
requests in the last few days of the merge window.
Yes, the merge window is two weeks, but that's very much to allow me
time to look things over, not "two weeks to hurriedly put together a
branch that you send Linus on Friday of the second week". The whole
"do an all-nighter to get the paper in the day before the dealine" is
something that should have gone out the window after highschool. Not
for kernel development.
The rule is that things that get sent to me should be ready *before*
the merge window opens, not be made ready during the merge window.
With some slack for "life happens", of course, but I really get the
feeling that a few people treat the end of the merge window as a
deadline, missing the whole "it was supposed to be ready before the
merge window".
You know who you are.
Anyway, it's not the first time I've said this, I doubt it will be the
last. But maybe more people could take it to heart, ok?
Enough kvetching, let's get this party calmed down. The merge window
may not be the biggest ever, but it's certainly big enough that the
shortlog is much too big to post, and below is just my usual merge
log. For all the gory details, please refer to the git tree.
Please get the testing started,
Linus
---
Al Viro (7):
coredump fix
vfs inode update
vfs d_path updates
vfs file updates
misc tomoyo changes
vfs constification updates
vfs tmpfile updates
Al Vrio (1):
file_inode() updates
Alex Williamson (1):
VFIO updates
Alexandre Belloni (2):
i3c updates
RTC updates
Andreas Gruenbacher (2):
gfs2 updates
gfs2 debugfs updates
Andrew Morton (4):
MM updates
non-MM updates
misc hotfixes
more MM updates
Anna Schumaker (1):
NFS client updates
Ard Biesheuvel (1):
EFI updates
Arnaldo Carvalho de Melo (2):
perf tools updates
more perf tools updates
Arnd Bergmann (7):
ARM defconfig updates
ARM driver updates
ARM devicetree updates
ARM SoC updates
asm-generic updates
ARM SoC fixes
asm-generic fix
Bartosz Golaszewski (1):
gpio updates
Benjamin Tissoires (1):
HID updates
Bjorn Andersson (2):
rpmsg updates
remoteproc updates
Bjorn Helgaas (2):
pci updates
pci fix
Borislav Petkov (14):
EDAC updates
x86 platform update
x86 RTC cleanups
x86 SGX update
x86 cpu updates
x86 RAS updates
x86 APIC update
x86 core fixes
x86 asm update
misc x86 fixes
x86 paravirt fix
x75 microcode loader updates
x86 cache resource control updates
x86 cleanups
Casey Schaufler (1):
smack updates
Catalin Marinas (2):
arm64 updates
arm64 fixes
Christian Brauner (2):
vfs acl updates
fatfs vfsuid conversion
Christoph Hellwig (1):
dma-mapping updates
Chuck Lever (2):
nfsd updates
more nfsd updates
Corey Minyard (1):
IPMI updates
Damien Le Moal (1):
ata updates
Dan Williams (1):
nvdimm updates
Darrick Wong (1):
iomap updates
Dave Airlie (3):
drm updates
drm fix
more drm updates
Dave Chinner (1):
xfs updates
Dave Hansen (1):
x86 mm updates
David Sterba (2):
btrfs updates
affs update
David Teigland (1):
dlm updates
Dmitry Torokhov (1):
input updates
Dominik Brodowski (1):
PCMCIA updates
Dominique Martinet (1):
9p updates
Eric Biederman (4):
kthread update
mqueue fix
ptrace update
ucounts update
Eric Biggers (3):
fscrypt updates
fsverity updates
STATX_DIOALIGN support
Gao Xiang (1):
erofs updates
Geert Uytterhoeven (1):
m68k updates
Greg KH (5):
tty/serial driver updates
USB / Thunderbolt updates
driver core updates
char/misc and other driver updates
staging driver updates
Greg Ungerer (1):
m68knommu updates
Guenter Roeck (1):
hwmon updates
Hans de Goede (1):
x86 platform driver updates
Helge Deller (2):
fbdev updates
parisc updates
Herbert Xu (1):
crypto updates
Huacai Chen (1):
LoongArch updates
Ilya Dryomov (1):
ceph updates
Ingo Molnar (5):
scheduler updates
perf events updates
locking updates
objtool updates
PSI updates
Jaegeuk Kim (1):
f2fs updates
Jakub Kicinski (2):
networking updates
networking fixes
James Bottomley (1):
SCSI updates
Jan Kara (2):
fsnotify updates
ext2, udf, reiserfs, and quota updates
Jarkko Sakkinen (1):
tpm updates
Jason Donenfeld (2):
random number generator updates
more random number generator updates
Jason Gunthorpe (1):
rdma updates
Jassi Brar (1):
mailbox updates
Jean Delvare (1):
dmi updates
Jens Axboe (5):
io_uring updates
block updates
passthrough updates
more io_uring updates
more block updates
Joerg Roedel (1):
iommu updates
Jonathan Corbet (2):
documentation updates
documentation fixes
Juergen Gross (1):
xen updates
Kees Cook (4):
Rust introductory support
execve updates
kcfi updates
kernel hardening updates
Lee Jones (2):
backlight update
MFD updates
Linus Walleij (1):
pin control updates
Luis Chamberlain (2):
module updates
sysctl updates
Mark Brown (3):
regmap updates
regulator updates
spi updates
Masahiro Yamada (2):
Kbuild updates
Kbuild fixes
Mauro Carvalho Chehab (1):
media updates
Max Filippov (1):
xtensa updates
Michael Ellerman (2):
powerpc updates
powerpc fixes
Michael Tsirkin (2):
virtio updates
virtio fixes
Michal Simek (1):
microblaze updates
Mickaël Salaün (1):
landlock updates
Mike Marshall (1):
orangefs update
Mike Rapoport (1):
memblock updates
Mimi Zohar (1):
integrity updates
Miquel Raynal (1):
MTD updates
Palmer Dabbelt (2):
RISC-V updates
more RISC-V updates
Paolo Bonzini (2):
kvm updates
more kvm updates
Paul McKenney (3):
nolibc updates
LKMM (Linux Kernel Memory Model) updates
RCU updates
Paul Moore (3):
SELinux updates
LSM updates
audit updates
Pavel Machek (1):
LED updates
Petr Mladek (2):
printk updates
livepatching updates
Rafael Wysocki (6):
ACPI updates
power management updates
thermal control updates
more ACPI updates
more power management updates
more thermal control updates
Richard Weinberger (2):
UML updates
UBI and UBIFS updates
Rob Herring (2):
devicetree updates
devicetree fixes
Russell King (2):
ARM fixes
ARM updates
Sebastian Reichel (2):
HSI updates
power supply and reset updates
Shuah Khan (4):
Kselftest updates
KUnit updates
more Kselftest updates
more KUnit updates
Stafford Horne (1):
OpenRISC updates
Stephen Boyd (2):
clk updates
more clk updates
Steve French (3):
ksmbd updates
cifs updates
more cifs updates
Steven Rostedt (2):
tracing updates
tracing fixes
Takashi Iwai (2):
sound updates
sound fixes
Ted Ts'o (1):
ext4 updates
Tejun Heo (1):
cgroup updates
Thierry Reding (1):
pwm updates
Thomas Bogendoerfer (1):
MIPS updates
Thomas Gleixner (3):
preempt RT updates
timer updates
interrupt updates
Tzung-Bi Shih (1):
chrome platform updates
Ulf Hansson (2):
MMC updates
MMC fixes
Vasily Gorbik (2):
s390 updates
more s390 updates
Vinod Koul (3):
dmaengine updates
phy updates
soundwire updates
Vlastimil Babka (2):
slab fixes
slab hotfix
Wei Liu (1):
hyperv updates
Wim Van Sebroeck (1):
watchdog updates
Wolfram Sang (2):
i2c updates
more i2c updates
Yury Norov (1):
bitmap updates
Hi all,
As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)
(No merge commits counted, next-20221004 was the first linux-next after
the merge window opened.)
Commits in v6.1-rc1 (relative to v6.0): 11537
Commits in next-20221004: 11354
Commits with the same SHA1: 10436
Commits with the same patch_id: 342 (1)
Commits with the same subject line: 20 (1)
(1) not counting those in the lines above.
So commits in -rc1 that were in next-20221004: 10798 93%
Some breakdown of the list of extra commits (relative to next-20221004)
in -rc1:
Top ten first word of commit summary:
122 perf
98 drm
23 wifi
21 pci
21 dt-bindings
20 net
18 tracing
16 rtc
16 clk
16 alsa
Top ten authors:
28 [email protected]
23 [email protected]
21 [email protected]
16 [email protected]
14 [email protected]
13 [email protected]
12 [email protected]
11 [email protected]
9 [email protected]
9 [email protected]
Top ten commiters:
124 [email protected]
96 [email protected]
33 [email protected]
32 [email protected]
30 [email protected]
29 [email protected]
22 [email protected]
20 [email protected]
18 [email protected]
18 [email protected]
There are also 556 commits in next-20221004 that didn't make it into
v6.1-rc1.
Top ten first word of commit summary:
163 media
47 apparmor
42 arm
30 thermal
28 fs
17 dt-bindings
16 scsi
15 drm
13 mm
11 soc
Top ten authors:
41 [email protected]
40 [email protected]
36 [email protected]
30 [email protected]
22 [email protected]
22 [email protected]
15 [email protected]
12 [email protected]
11 [email protected]
11 [email protected]
Top ten commiters:
163 [email protected]
47 [email protected]
42 [email protected]
30 [email protected]
23 [email protected]
22 [email protected]
18 [email protected]
18 [email protected]
16 [email protected]
15 [email protected]
--
Cheers,
Stephen Rothwell
Started getting this during mount on a 6.1rc1 kernel..
not sure which mount it's complaining about, but they're all v3 tcp
mounts on that machine.
[ 19.617475] memcpy: detected field-spanning write (size 28) of single field "request.sap" at fs/nfs/super.c:857 (size 18446744073709551615)
[ 19.617504] WARNING: CPU: 3 PID: 1300 at fs/nfs/super.c:857 nfs_request_mount.constprop.0.isra.0+0x1c0/0x1f0
[ 19.617528] CPU: 3 PID: 1300 Comm: mount.nfs Not tainted 6.1.0-rc1-backup+ #1
[ 19.617553] RIP: 0010:nfs_request_mount.constprop.0.isra.0+0x1c0/0x1f0
[ 19.617566] Code: 16 81 01 00 75 9b 48 c7 c1 ff ff ff ff 48 c7 c2 a8 a8 82 ab 4c 89 e6 c6 05 36 16 81 01 01 48 c7 c7 a8 3a 81 ab e8 61 1d 9a 00 <0f> 0b 48 8b 3c 24 e9 6c ff ff ff c7 83 20 01 00 00 01 00 00 00 b8
[ 19.617593] RSP: 0018:ffffc900027fbd48 EFLAGS: 00010286
[ 19.617604] RAX: 0000000000000000 RBX: ffff8881208d5000 RCX: ffff88842fadb7a8
[ 19.617617] RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff88842fadb7a0
[ 19.617629] RBP: ffff8881208d5130 R08: 0000000000000000 R09: ffffffffaba5c540
[ 19.617641] R10: 0000000000000001 R11: 0000000000000001 R12: 000000000000001c
[ 19.617653] R13: 0000000000000001 R14: ffffc900027fbef0 R15: ffff888100b3bea0
[ 19.617665] FS: 00007ff793dd6840(0000) GS:ffff88842fac0000(0000) knlGS:0000000000000000
[ 19.617679] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 19.617690] CR2: 0000564a1a747468 CR3: 00000001106fb003 CR4: 00000000001706e0
[ 19.617703] Call Trace:
[ 19.617709] <TASK>
[ 19.617716] nfs_try_get_tree+0xa1/0x220
[ 19.617725] ? get_nfs_version+0x63/0x130
[ 19.617736] vfs_get_tree+0x1d/0x90
[ 19.617746] ? capable+0x2f/0x50
[ 19.617755] path_mount+0x75c/0xb00
[ 19.617766] __x64_sys_mount+0x19a/0x200
[ 19.617775] do_syscall_64+0x35/0x80
[ 19.617785] entry_SYSCALL_64_after_hwframe+0x46/0xb0
[ 19.617796] RIP: 0033:0x7ff7941ac6ea
[ 19.617805] Code: 48 8b 0d a9 17 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 76 17 0d 00 f7 d8 64 89 01 48
[ 19.617832] RSP: 002b:00007ffd02ae4ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
[ 19.617846] RAX: ffffffffffffffda RBX: 00007ffd02ae4e70 RCX: 00007ff7941ac6ea
[ 19.617858] RDX: 0000564a1a73fb60 RSI: 0000564a1a73fb80 RDI: 0000564a1a741890
[ 19.617870] RBP: 00007ff793dd67b8 R08: 0000564a1a73f480 R09: 0000564a1a73f480
[ 19.617882] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 19.617894] R13: 00007ffd02ae4dd0 R14: 0000564a1a7474e0 R15: 0000564a1a7436b0
[ 19.617907] </TASK>
[ 19.617913] irq event stamp: 8757
[ 19.617920] hardirqs last enabled at (8769): [<ffffffffaa1397c2>] __up_console_sem+0x52/0x60
[ 19.617937] hardirqs last disabled at (8780): [<ffffffffaa1397a7>] __up_console_sem+0x37/0x60
[ 19.617952] softirqs last enabled at (8180): [<ffffffffaabf547a>] sk_common_release+0x5a/0xe0
[ 19.617969] softirqs last disabled at (8178): [<ffffffffaabf5456>] sk_common_release+0x36/0xe0
[ 19.617984] ---[ end trace 0000000000000000 ]---
Dave
On 10/17/22 11:17, Kees Cook wrote:
> On Mon, Oct 17, 2022 at 10:58:55AM +0700, Bagas Sanjaya wrote:
>> On Sun, Oct 16, 2022 at 10:58:21PM -0400, Dave Jones wrote:
>>> Started getting this during mount on a 6.1rc1 kernel..
>>> not sure which mount it's complaining about, but they're all v3 tcp
>>> mounts on that machine.
>>>
>>> [ 19.617475] memcpy: detected field-spanning write (size 28) of single field "request.sap" at fs/nfs/super.c:857 (size 18446744073709551615)
>> [...]
>> Hmm, the blamed line in the warning is introduced by 38465f5d1af932 ("NFS:
>> rename nfs_fs_context pointer arg in a few functions"). Cc: the commit
>> author. Also Cc: Kees for authoring the patch [1] that have fixed
>> similar warning.
>
> The warning is from commit 54d9469bc515 ("fortify: Add run-time WARN
> for cross-field memcpy()")
>
>> Also, does v6.0 have this warning? If so, you need to bisect in the range
>> of v6.0..v6.1-rc1.
>
> No need for bisection -- this is almost certainly a false positive (as
> detailed in the above commit: we're working on purging all of these
> cases from the kernel).
>
>> [1]: https://lore.kernel.org/lkml/[email protected]/
>
> Yeah, I have a v2 of this patch, which should also fix this request.sap
> issue. Sending shortly...
>
OK, thanks!
--
An old man doll... just what I always wanted! - Clara
On Sun, Oct 16, 2022 at 10:58:21PM -0400, Dave Jones wrote:
> [ 19.617475] memcpy: detected field-spanning write (size 28) of single field "request.sap" at fs/nfs/super.c:857 (size 18446744073709551615)
I've sent this, which should fix it:
https://lore.kernel.org/lkml/[email protected]/
However, the -1 size tells me something has gone slightly wrong with the
runtime warning, as it _should_ be ignoring destinations with "unknown"
size -- in this case, struct sockaddr has a trailing array, which is
treated (currently) as a fake flexible array, so __builtin_object_size()
is reporting the "-1". But with the coming -fstrict-flex-arrays, this
will need fixing anyway. I will re-check the runtime warning logic...
--
Kees Cook
On Sun, Oct 16, 2022 at 04:01:33PM -0700, Linus Torvalds wrote:
> You all know the drill: it's Sunday afternoon, the two weeks of merge
> window are over, and now we're supposed to start calming things down.
>
[ ... ]
> Please get the testing started,
>
Build results:
total: 152 pass: 152 fail: 0
Qemu test results:
total: 490 pass: 420 fail: 70
Failed tests:
<all big endian mips tests>
<all riscv tests>
---
The following patches are needed to fix the problems reported below.
Revert "net: fix cpu_max_bits_warn() usage in netif_attrmask_next{,_and}"
Revert "mfd: syscon: Remove repetition of the regmap_get_val_endian()"
RISC-V: KVM: Fix compilation without RISCV_ISA_ZICBOM
powerpc/64s: make linear_map_hash_lock a raw spinlock
powerpc/64s: make HPTE lock and native_tlbie_lock irq-safe
powerpc/64s: Add lockdep for HPTE lock
powerpc: fix reschedule bug in KUAP-unlocked user copy
powerpc/64s: Fix hash__change_memory_range preemption warning
powerpc/64s: Disable preemption in hash lazy mmu mode
---
Build failures
Building riscv:defconfig ... failed
--------------
Error log:
ERROR: modpost: "riscv_cbom_block_size" [arch/riscv/kvm/kvm.ko] undefined!
Caused by commit afd5dde9a186 ("RISC-V: KVM: Provide UAPI for Zicbom block
size"). Suggested fix is at
https://patchwork.kernel.org/project/linux-riscv/patch/[email protected]/
Last time I checked (10/14) it was still under discussion.
Cc: Andrew Jones <[email protected]>
Cc: Conor Dooley <[email protected]>
Cc: Atish Patra <[email protected]>
Cc: Anup Patel <[email protected]>
================
Runtime failures / warnings
powerpc
-------
BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
caller is .__apply_to_page_range+0x734/0xa20
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-12130-g73344a3f6793 #1
Hardware name: PowerMac3,1 PPC970FX 0x3c0301 PowerMac
Call Trace:
[c0000000056075b0] [c000000001085308] .dump_stack_lvl+0xa4/0x100 (unreliable)
[c000000005607640] [c0000000010ba384] .check_preemption_disabled+0x144/0x150
[c0000000056076e0] [c000000000371464] .__apply_to_page_range+0x734/0xa20
[c000000005607820] [c00000000006e21c] .change_memory_attr+0xfc/0x160
[c0000000056078b0] [c0000000002ce778] .bpf_prog_select_runtime+0x78/0x220
[c000000005607950] [c000000000de3a68] .bpf_prepare_filter+0xa18/0xa80
[c000000005607a10] [c000000000de3b6c] .bpf_prog_create+0x9c/0x110
[c000000005607aa0] [c00000000205e0c4] .ptp_classifier_init+0x44/0x78
[c000000005607b30] [c00000000205d260] .sock_init+0xd8/0xf8
[c000000005607bb0] [c000000000010e28] .do_one_initcall+0xa8/0x528
[c000000005607ca0] [c00000000200501c] .kernel_init_freeable+0x3c8/0x478
[c000000005607d90] [c0000000000116bc] .kernel_init+0x2c/0x1c0
[c000000005607e10] [c00000000000ca3c] .ret_from_kernel_thread+0x58/0x60
Not a new problem (seen as far back as v5.15.y), but fixed by:
"powerpc/64s: Disable preemption in hash lazy mmu mode"
"powerpc/64s: Fix hash__change_memory_range preemption warning"
"powerpc: fix reschedule bug in KUAP-unlocked user copy"
at:
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/[email protected]/
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/[email protected]/
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/[email protected]/
================================
WARNING: inconsistent lock state
6.0.0-12130-g73344a3f6793 #1 Tainted: G N
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
swapper/0/1 [HC0[0]:SC0[0]:HE1:SE1] takes:
c000000002734de8 (native_tlbie_lock){+.?.}-{2:2}, at: .native_hpte_updateboltedpp+0x1a4/0x600
{IN-SOFTIRQ-W} state was registered at:
.lock_acquire+0x20c/0x520
._raw_spin_lock+0x4c/0x70
.native_hpte_invalidate+0x62c/0x840
Fixed by:
"powerpc/64s: Add lockdep for HPTE lock"
"powerpc/64s: make HPTE lock and native_tlbie_lock irq-safe"
"powerpc/64s: make linear_map_hash_lock a raw spinlock:
at
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/[email protected]/
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/[email protected]/
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/[email protected]/
mips, sparc64
-------------
All big endian mips tests fail to reset after boot. The problem is
caused by commit 72a95859728a ("mfd: syscon: Remove repetition of the
regmap_get_val_endian()").
Cc: Hector Martin <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Lee Jones <[email protected]>
---
The riscv build failure is hiding a new runtime warning, seen with
32-bit and 64-bit riscv boot tests after the fix for the build problem
was applied.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at include/linux/cpumask.h:110 __netif_set_xps_queue+0x194/0x976
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-12199-g277163563de8 #1
Hardware name: riscv-virtio,qemu (DT)
epc : __netif_set_xps_queue+0x194/0x976
ra : __netif_set_xps_queue+0x3b0/0x976
epc : c089a664 ra : c089a880 sp : c2515c60
gp : c1d8e760 tp : c2578040 t0 : c364f980
t1 : 00000000 t2 : 00001fff s0 : c2515cd0
s1 : c2515ce4 a0 : c364f940 a1 : 00000000
a2 : c364f940 a3 : 00000000 a4 : c364f950
a5 : c364f890 a6 : 00000003 a7 : 00000000
s2 : 00000001 s3 : c1d382c0 s4 : 00000000
s5 : 00000000 s6 : 00000000 s7 : c364f880
s8 : 00000000 s9 : 00000001 s10: 00000001
s11: 00000000 t3 : 00000018 t4 : 7fd38a0e
t5 : 00000007 t6 : c3639470
status: 00000120 badaddr: 00000000 cause: 00000003
[<c074548a>] virtnet_set_affinity+0x13a/0x1a2
[<c07478de>] virtnet_probe+0x884/0xfdc
[<c063ce9a>] virtio_dev_probe+0x1d6/0x354
[<c0683d6e>] really_probe+0x82/0x214
[<c0683f58>] __driver_probe_device+0x58/0xa2
[<c0683fd2>] driver_probe_device+0x30/0xaa
[<c0684596>] __driver_attach+0x56/0x11c
[<c0681f26>] bus_for_each_dev+0x52/0x90
[<c06837c0>] driver_attach+0x1a/0x22
[<c068331a>] bus_add_driver+0x148/0x1b6
[<c0684d70>] driver_register+0x52/0xea
[<c063c924>] register_virtio_driver+0x1a/0x28
[<c0c2428e>] virtio_net_driver_init+0x7a/0xa6
[<c0002824>] do_one_initcall+0x5e/0x2e2
[<c0c01130>] kernel_init_freeable+0x298/0x306
[<c0aa0ac2>] kernel_init+0x1e/0x10e
[<c0003ad8>] ret_from_exception+0x0/0x10
irq event stamp: 106012
hardirqs last enabled at (106011): [<c0aa9284>] _raw_spin_unlock_irqrestore+0x54/0x62
hardirqs last disabled at (106012): [<c0007534>] __trace_hardirqs_off+0xc/0x14
softirqs last enabled at (105764): [<c0886392>] napi_get_frags_check+0x0/0x50
softirqs last disabled at (105758): [<c0886392>] napi_get_frags_check+0x0/0x50
---[ end trace 0000000000000000 ]---
This is is caused (triggered ? exposed ?) by commit 854701ba4c39
("net: fix cpu_max_bits_warn() usage in netif_attrmask_next{,_and}").
A revert for this patch is at:
https://lore.kernel.org/netdev/166582921612.1299.769135677399153914.git-patchwork-notify@kernel.org/T/#m0111a76380626b2f91e072ecdd5827578d5cbf60
This revert has been applied to the net tree.
Cc: Yury Norov <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Rasmus Villemoes <[email protected]>
Cc: Guo Ren <[email protected]>
Cc: Jakub Kicinski <[email protected]>
On Mon, Oct 17, 2022 at 5:35 AM Guenter Roeck <[email protected]> wrote:
>
> Build results:
> total: 152 pass: 152 fail: 0
> Qemu test results:
> total: 490 pass: 420 fail: 70
Strange. You claim zero build failures, but then:
> Build failures
>
> Building riscv:defconfig ... failed
so I think your stats may be wrong somehow ;)
> mips, sparc64
> -------------
>
> All big endian mips tests fail to reset after boot. The problem is
> caused by commit 72a95859728a ("mfd: syscon: Remove repetition of the
> regmap_get_val_endian()").
Bah. I had already archived that whole thread as "sorted out", but
yeah, the revert clearly never made it to me for rc1.
But it should be in the regmap queue (Lee/Andy?), so it is hopefully
just a temporary thing.
In fact, it looks like all the failures have known fixes. So here's
hoping that your list will be a whole lot cleaner by rc2.
Knock wood.
Thanks,
Linus
On 10/17/22 10:39, Linus Torvalds wrote:
> On Mon, Oct 17, 2022 at 5:35 AM Guenter Roeck <[email protected]> wrote:
>>
>> Build results:
>> total: 152 pass: 152 fail: 0
>> Qemu test results:
>> total: 490 pass: 420 fail: 70
>
> Strange. You claim zero build failures, but then:
>
>> Build failures
>>
>> Building riscv:defconfig ... failed
>
> so I think your stats may be wrong somehow ;)
>
Puzzled ... the logs show that the builds for riscv[32/64] succeeded
with no error, but a manual build test still shows the failure.
Ah .... the build fails with gcc 11.3.0 / binutils 2.38, but passes
with gcc 11.3.0 / binutils 2.39. I had switched my builders to the
latter last night to fix a problem with powerpc builds. At the same time,
the manual test I just ran still used binutils 2.38.
That is interesting; I didn't expect that the binutils version would
make a difference, but apparently it does. Comparing defconfig:
10c10
< CONFIG_AS_VERSION=23900
---
> CONFIG_AS_VERSION=23800
12c12
< CONFIG_LD_VERSION=23900
---
> CONFIG_LD_VERSION=23800
260d259
< CONFIG_RISCV_DMA_NONCOHERENT=y
297,298d295
< CONFIG_CC_HAS_ZICBOM=y
< CONFIG_RISCV_ISA_ZICBOM=y
4134,4137d4130
< CONFIG_ARCH_HAS_SETUP_DMA_OPS=y
< CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y
< CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU=y
< CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y
4140,4142d4132
< CONFIG_DMA_NONCOHERENT_MMAP=y
< CONFIG_DMA_COHERENT_POOL=y
< CONFIG_DMA_DIRECT_REMAP=y
The build failure is only seen with CONFIG_RISCV_ISA_ZICBOM=n,
or in other words with binutils 2.38 or earlier.
>> mips, sparc64
>> -------------
>>
>> All big endian mips tests fail to reset after boot. The problem is
>> caused by commit 72a95859728a ("mfd: syscon: Remove repetition of the
>> regmap_get_val_endian()").
>
> Bah. I had already archived that whole thread as "sorted out", but
> yeah, the revert clearly never made it to me for rc1.
>
Yes, I saw a note along that line. The original reboot failure affected
sparc64 boot tests as well, which is gone now. Maybe some other fix for
the mips problem is in the works ?
> But it should be in the regmap queue (Lee/Andy?), so it is hopefully
> just a temporary thing.
>
> In fact, it looks like all the failures have known fixes. So here's
> hoping that your list will be a whole lot cleaner by rc2.
>
Hopefully yes.
Thanks,
Guenter
On Mon, Oct 17, 2022 at 11:28:53AM -0700, Guenter Roeck wrote:
> On 10/17/22 10:39, Linus Torvalds wrote:
> > On Mon, Oct 17, 2022 at 5:35 AM Guenter Roeck <[email protected]> wrote:
> > >
> > > Build results:
> > > total: 152 pass: 152 fail: 0
> > > Qemu test results:
> > > total: 490 pass: 420 fail: 70
> >
> > Strange. You claim zero build failures, but then:
> >
> > > Build failures
> > >
> > > Building riscv:defconfig ... failed
> >
> > so I think your stats may be wrong somehow ;)
> >
>
> Puzzled ... the logs show that the builds for riscv[32/64] succeeded
> with no error, but a manual build test still shows the failure.
>
> Ah .... the build fails with gcc 11.3.0 / binutils 2.38, but passes
> with gcc 11.3.0 / binutils 2.39. I had switched my builders to the
> latter last night to fix a problem with powerpc builds. At the same time,
> the manual test I just ran still used binutils 2.38.
>
> That is interesting; I didn't expect that the binutils version would
> make a difference, but apparently it does. Comparing defconfig:
>
> 10c10
> < CONFIG_AS_VERSION=23900
> ---
> > CONFIG_AS_VERSION=23800
> 12c12
> < CONFIG_LD_VERSION=23900
> ---
> > CONFIG_LD_VERSION=23800
> 260d259
> < CONFIG_RISCV_DMA_NONCOHERENT=y
> 297,298d295
> < CONFIG_CC_HAS_ZICBOM=y
> < CONFIG_RISCV_ISA_ZICBOM=y
> 4134,4137d4130
> < CONFIG_ARCH_HAS_SETUP_DMA_OPS=y
> < CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y
> < CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU=y
> < CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y
> 4140,4142d4132
> < CONFIG_DMA_NONCOHERENT_MMAP=y
> < CONFIG_DMA_COHERENT_POOL=y
> < CONFIG_DMA_DIRECT_REMAP=y
>
> The build failure is only seen with CONFIG_RISCV_ISA_ZICBOM=n,
> or in other words with binutils 2.38 or earlier.
+CC Palmer since he's the maintainer of the code being changed by the
fix.
The Zicbom extension only got support in binutils 2.39, so it's
automatically disabled for your older binutils, along with non-coherent
DMA support. As pointed out, we've already got a reviewed fix for it, so
hopefully that lands soon.
Kinda surprised this didn't trigger complaints from more than just you
and an LKP report, but it may be that having some other options selected
hides the problem.
Palmer, the fix is here if you get a chance to look at it:
https://lore.kernel.org/all/[email protected]/
Thanks,
Conor.
On Mon, Oct 17, 2022 at 10:39:08AM -0700, Linus Torvalds wrote:
> On Mon, Oct 17, 2022 at 5:35 AM Guenter Roeck <[email protected]> wrote:
> >
> > Build results:
> > total: 152 pass: 152 fail: 0
> > Qemu test results:
> > total: 490 pass: 420 fail: 70
>
> Strange. You claim zero build failures, but then:
>
> > Build failures
> >
> > Building riscv:defconfig ... failed
>
> so I think your stats may be wrong somehow ;)
>
> > mips, sparc64
> > -------------
> >
> > All big endian mips tests fail to reset after boot. The problem is
> > caused by commit 72a95859728a ("mfd: syscon: Remove repetition of the
> > regmap_get_val_endian()").
>
> Bah. I had already archived that whole thread as "sorted out", but
> yeah, the revert clearly never made it to me for rc1.
>
> But it should be in the regmap queue (Lee/Andy?), so it is hopefully
> just a temporary thing.
>
> In fact, it looks like all the failures have known fixes. So here's
> hoping that your list will be a whole lot cleaner by rc2.
>
> Knock wood.
I emailed Lee about it 3 days ago, hoping it'd make rc1 too, but never
heard back. Maybe vacation? Dunno.
Jason
>
> Thanks,
> Linus