lkml.org 
[lkml]   [2022]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 5.19-rc7
On Sun, Jul 17, 2022 at 02:02:37PM -0700, Linus Torvalds wrote:
> It's a Sunday afternoon, I wonder what that might mean..
>
> Another week, another rc. We obviously had that whole "Retbleed"
> thing, and it does show up in both the diffstat and the shortlog, and
> rc7 is definitely bigger than usual.
>
> And also as usual, when we've had one of those embargoed hw issues
> pending, the patches didn't get the open development, and then as a
> result missed all the usual sanity checking by all the automation
> build and test infrastructure we have. So no surprise - there's been
> various small fixup patches afterwards too for some corner cases.
>
> That said, last week there were two other development trees that
> independently also asked for an extension, so 5.19 will be one of
> those releases that have an additional rc8 next weekend before the
> final release. We had some last-minute btrfs reverts, and there's also
> a pending issue with a intel GPU firmware.
>
> When it rains it pours.
>
> Not that things really look all that bad. I think we've got the
> retbleed fallout all handled (knock wood), and the btrfs reverts are
> in place. And the Intel GPU firmware issue seems to have a patch
> pending too (or we'll just revert). So it's not like we have any huge
> issues, but an extra week is most definitely called for.
>

Build results look good.

Build results:
total: 150 pass: 150 fail: 0
Qemu test results:
total: 489 pass: 489 fail: 0

As for warnings, I see

[ 19.798382] test_bitmap: parselist: 14: input is '0-2047:128/256' OK, Time: 12584
[ 19.803177] ==================================================================
[ 19.803628] BUG: KFENCE: out-of-bounds read in _find_next_bit_le+0x10/0x48
[ 19.803628]
[ 19.804846] Out-of-bounds read at 0xef5b2000 (4096B right of kfence-#103):
[ 19.805333] _find_next_bit_le+0x10/0x48
[ 19.805561]
[ 19.805782] kfence-#103: 0xef5b1000-0xef5b1fff, size=4096, cache=kmalloc-4k
[ 19.805782]
[ 19.806263] allocated by task 1 on cpu 1 at 19.800216s:
[ 19.806797] test_bitmap_printlist+0x2c/0x13c
[ 19.807024] test_bitmap_init+0x64/0x478
[ 19.807197] do_one_initcall+0x6c/0x3a4
[ 19.807380] kernel_init_freeable+0x1c4/0x230
[ 19.807568] kernel_init+0x18/0x130
[ 19.807729] ret_from_fork+0x14/0x2c
[ 19.807885] 0x0
[ 19.808520] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc7 #1
[ 19.808924] Hardware name: Samsung Exynos (Flattened Device Tree)
[ 19.809301] PC is at _find_next_bit_le+0x10/0x48
[ 19.809516] LR is at bitmap_list_string.constprop.0+0xfc/0x144
[ 19.809775] pc : [<c06ff0cc>] lr : [<c0715870>] psr: 20000113
[ 19.810033] sp : f082dc70 ip : 00000001 fp : 00000001
[ 19.810254] r10: 00000000 r9 : 0000002d r8 : ef5b1000
[ 19.810478] r7 : c0e55514 r6 : c2215000 r5 : 00008000 r4 : 00008000
[ 19.810746] r3 : 3163db73 r2 : 00008001 r1 : 00008000 r0 : ef5b1000
[ 19.811082] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 19.811418] Control: 10c5387d Table: 4000406a DAC: 00000051
[ 19.811791] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc7 #1
[ 19.812049] Hardware name: Samsung Exynos (Flattened Device Tree)
[ 19.812437] unwind_backtrace from show_stack+0x10/0x14
[ 19.812723] show_stack from dump_stack_lvl+0x68/0x90
[ 19.812953] dump_stack_lvl from kfence_report_error+0x260/0x664
[ 19.813231] kfence_report_error from kfence_handle_page_fault+0x1ec/0x27c
[ 19.813515] kfence_handle_page_fault from __do_kernel_fault.part.0+0x3c/0x74
[ 19.813799] __do_kernel_fault.part.0 from do_page_fault+0x1d0/0x408
[ 19.814070] do_page_fault from do_DataAbort+0x3c/0xb4
[ 19.814292] do_DataAbort from __dabt_svc+0x50/0x80
[ 19.814614] Exception stack(0xf082dc20 to 0xf082dc68)
[ 19.815104] dc20: ef5b1000 00008000 00008001 3163db73 00008000 00008000 c2215000 c0e55514
[ 19.815460] dc40: ef5b1000 0000002d 00000000 00000001 00000001 f082dc70 c0715870 c06ff0cc
[ 19.815773] dc60: 20000113 ffffffff
[ 19.815964] __dabt_svc from _find_next_bit_le+0x10/0x48

which I don't recall seeing before. Digging into it, it may be spurious
(ie seen with various emulations and not with every boot), and it looks
like it is not not a new problem: I see the same or a similar report
in v5.18.y, but never in v5.15.y. I'll try to bisect.

Guenter

\
 
 \ /
  Last update: 2022-07-18 04:33    [W:0.080 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site