linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Peter Zijlstra <peterz@infradead.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Kees Cook <keescook@chromium.org>
Subject: Re: Linux 6.2-rc1
Date: Mon, 26 Dec 2022 11:52:06 -0800	[thread overview]
Message-ID: <20221226195206.GA2626419@roeck-us.net> (raw)
In-Reply-To: <CAHk-=wgf929uGOVpiWALPyC7pv_9KbwB2EAvQ3C4woshZZ5zqQ@mail.gmail.com>

On Sun, Dec 25, 2022 at 02:07:05PM -0800, Linus Torvalds wrote:
> So it's Christmas Day here, but it's also Sunday afternoon two weeks
> after the 6.2 merge window opened. So holidays or not, the kernel
> development show must go on.
> 
> Thanks to a lot of people sending their pull requests early, I got
> much of the merge window work done before the holidays started in
> earnest, and mostly before my pre-xmas travel. So despite flight
> delays, missed connections, and the resulting airport hotel
> excursions, the merge window mostly went smoothly, and there was no
> reason to delay rc1.
> 
> That said, realistically I expect most people to be on vacation for at
> least another week, so I wouldn't be surprised if we end up with a
> delayed final release due to the season. But it's too early to worry
> about that yet, we'll just have to see how it goes.
> 
> Also, 6.2 looks like it's a bigger release (certainly bigger than 6.1
> was). The summary below is, as usual, just my merge log: we've got
> about 13.5k commits from ~1800 people in total in this merge window,
> which is actually not that far off the total size of the whole 6.1
> release. But let's hope that despite the size, and despite the likely
> slow start of the post-merge-window calming down period, we'll have a
> smooth release.
> 

Test results:

Build results:
	total: 155 pass: 151 fail: 4
Failed builds:
	powerpc:allmodconfig
	sh:defconfig
	sh:shx3_defconfig
	xtensa:allmodconfig
Qemu test results:
	total: 500 pass: 498 fail: 2
Failed tests:
	arm:xilinx-zynq-a9:multi_v7_defconfig:usb0:mem128:net,default:zynq-zc702:rootfs
	arm:xilinx-zynq-a9:multi_v7_defconfig:usb0:mem128:zynq-zed:rootfs

Details below.

Guenter

---
Build errors
============

Building powerpc:allmodconfig ... failed
--------------
Error log:
In file included from include/linux/string.h:253,
                 from arch/powerpc/include/asm/paca.h:16,
                 from arch/powerpc/include/asm/current.h:13,
                 from include/linux/thread_info.h:23,
                 from include/asm-generic/preempt.h:5,
                 from ./arch/powerpc/include/generated/asm/preempt.h:1,
                 from include/linux/preempt.h:78,
                 from include/linux/spinlock.h:56,
                 from include/linux/wait.h:9,
                 from include/linux/wait_bit.h:8,
                 from include/linux/fs.h:6,
                 from fs/f2fs/inline.c:9:
fs/f2fs/inline.c: In function 'f2fs_move_inline_dirents':
include/linux/fortify-string.h:59:33: error: '__builtin_memset' pointer overflow between offset [28, 898293814] and size [-898293787, -1] [-Werror=array-bounds]
   59 | #define __underlying_memset     __builtin_memset
      |                                 ^
include/linux/fortify-string.h:337:9: note: in expansion of macro '__underlying_memset'
  337 |         __underlying_memset(p, c, __fortify_size);                      \
      |         ^~~~~~~~~~~~~~~~~~~
include/linux/fortify-string.h:345:25: note: in expansion of macro '__fortify_memset_chk'
  345 | #define memset(p, c, s) __fortify_memset_chk(p, c, s,                   \
      |                         ^~~~~~~~~~~~~~~~~~~~
fs/f2fs/inline.c:430:9: note: in expansion of macro 'memset'
  430 |         memset(dst.bitmap + src.nr_bitmap, 0, dst.nr_bitmap - src.nr_bitmap);
      |         ^~~~~~
cc1: all warnings being treated as errors

xtensa:allmodconfig

Building xtensa:allmodconfig ... failed
--------------
Error log:
kernel/kcsan/kcsan_test.c: In function '__report_matches':
kernel/kcsan/kcsan_test.c:257:1: error: the frame size of 1680 bytes is larger than 1536 bytes

Bisect for both points to commit e240e53ae0abb08 ("mm, slub: add
CONFIG_SLUB_TINY").  Reverting it on its own is not possible, but
reverting the following two patches fixes the problem.

149b6fa228ed mm, slob: rename CONFIG_SLOB to CONFIG_SLOB_DEPRECATED
e240e53ae0ab mm, slub: add CONFIG_SLUB_TINY

Context: CONFIG_SLUB_TINY is enabled with allmodconfig builds.
This enables some previously disabled configurations and disables
some previously enabled configurations. Not sure if that is a good
thing or a bad thing, but it does result in the above errors.

---
sh:defconfig
sh:shx3_defconfig

Building sh:defconfig ... failed
--------------
Error log:
In file included from <command-line>:
In function 'follow_pmd_mask',
    inlined from 'follow_pud_mask' at mm/gup.c:735:9,
    inlined from 'follow_p4d_mask' at mm/gup.c:752:9,
    inlined from 'follow_page_mask' at mm/gup.c:809:9:
include/linux/compiler_types.h:358:45: error: call to '__compiletime_assert_263' declared with attribute error: Unsupported access size for {READ,WRITE}_ONCE().
  358 |         _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)

Bisect points to commit 0862ff059c9e ("sh/mm: Make pmd_t similar to pte_t").
This commit introduces

-typedef struct { unsigned long long pmd; } pmd_t;
+typedef struct {
+       struct {
+               unsigned long pmd_low;
+               unsigned long pmd_high;
+       };
+       unsigned long long pmd;
+} pmd_t;

That should probably be "typedef union", not "typedef struct".

=============

Runtime:

Boot tests of arm:xilinx-zynq-a9 fail after

[    5.849451] ci_hdrc ci_hdrc.0: failed to register ULPI interface
[    5.849577] ci_hdrc: probe of ci_hdrc.0 failed with error -110

Caused by commit 8a7b31d545d3 ("usb: ulpi: defer ulpi_register on
ulpi_read_id timeout"). Revert is pending.

---

Not exactly a regression, but worth mentioning:

CONFIG_MEMCPY_KUNIT_TEST now sometimes takes several minutes to
execute in qemu. On top of that, it may result in hung task timeouts
if the hung task timeout is set to low values (45 seconds and below).
Example, seen with s390:

...
[   18.494320]     ok 2 memcpy_test
[   52.969037]     ok 3 memcpy_large_test
...
[   52.974505]     ok 4 memmove_test
[   87.325400]     ok 5 memmove_large_test
[  143.562760] INFO: task swapper/0:1 blocked for more than 46 seconds.
...
[  143.564441] Call Trace:
[  143.564689]  [<0000000000f1ec80>] __schedule+0x370/0x720
[  143.565175]  [<0000000000f1f098>] schedule+0x68/0x110
[  143.565374]  [<0000000000f278d4>] schedule_timeout+0xc4/0x160
[  143.565603]  [<0000000000f1fde2>] __wait_for_common+0xda/0x250
[  143.565816]  [<0000000000903c90>] kunit_try_catch_run+0x98/0x178
[  143.566029]  [<0000000000f05c9c>] kunit_run_case_catch_errors+0x7c/0xb8
[  143.566956]  [<00000000009023c0>] kunit_run_tests+0x220/0x638
...

That is too much for my test bed. I dropped this test as result. This means
that extending the tests has, at least in the context of my testing, the
opposite effect.

  reply	other threads:[~2022-12-26 19:52 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-25 22:07 Linux 6.2-rc1 Linus Torvalds
2022-12-26 19:52 ` Guenter Roeck [this message]
2022-12-26 20:56   ` Linus Torvalds
2022-12-26 21:03     ` Kees Cook
2022-12-26 22:10       ` Guenter Roeck
2022-12-27  0:29       ` Guenter Roeck
2022-12-27  1:32         ` Kees Cook
2022-12-27  5:52           ` Guenter Roeck
2022-12-28  3:40             ` Kees Cook
2022-12-28 14:44               ` Guenter Roeck
2023-01-07  0:06                 ` Jaegeuk Kim
2022-12-26 22:41     ` Vlastimil Babka
2022-12-26 21:10   ` Max Filippov
2022-12-26 22:08     ` Guenter Roeck
2022-12-27  8:29 ` Build regressions/improvements in v6.2-rc1 Geert Uytterhoeven
2022-12-27  8:35   ` Geert Uytterhoeven
2023-01-01  1:33     ` Rob Landley
2023-01-01 12:24       ` Geert Uytterhoeven
2023-01-04  6:32         ` Michael Ellerman
2023-01-06 15:10     ` John Paul Adrian Glaubitz
2023-01-06 15:17       ` Geert Uytterhoeven
2023-01-06 15:18         ` Geert Uytterhoeven
2023-01-17 16:42         ` Calculating array sizes in C - was: " John Paul Adrian Glaubitz
2023-01-17 17:01           ` Geert Uytterhoeven
2023-01-17 17:06             ` John Paul Adrian Glaubitz
2023-01-17 20:05               ` Geert Uytterhoeven
2023-01-17 20:37                 ` John Paul Adrian Glaubitz
2023-01-19 22:11                   ` Michael.Karcher
2023-01-20  3:31                     ` Rob Landley
2023-01-20 10:53                       ` Segher Boessenkool
2023-01-20 18:29                         ` Michael.Karcher
2023-01-20  8:49                     ` John Paul Adrian Glaubitz
2023-01-20 19:29                       ` Michael Karcher
2023-01-21 21:26                         ` John Paul Adrian Glaubitz
2023-01-06 15:39     ` Alex Deucher
2023-01-04 19:01 ` Linux 6.2-rc1 Pali Rohár
2023-01-04 19:25   ` Linus Torvalds
2023-01-04 20:56     ` Pali Rohár
2023-01-04 21:27       ` Pali Rohár
2023-01-04 21:32       ` Linus Torvalds
2023-01-04 21:43         ` Jens Axboe
2023-01-05 11:25           ` Greg Kroah-Hartman
2023-01-05 15:26             ` Jens Axboe
2023-01-05 17:42           ` Pali Rohár
2023-01-05 17:45             ` Jens Axboe
2023-01-05 19:06               ` Linus Torvalds
2023-01-05 19:22                 ` Pali Rohár
2023-01-05 19:40                 ` Jens Axboe
2023-01-05 20:03                   ` Linus Torvalds
2023-01-05 20:33                     ` Jens Axboe
2023-01-06 16:58                       ` Pali Rohár
2023-01-06 17:04                         ` Jens Axboe
2023-01-28 19:34                           ` pktcdvd Pali Rohár
2023-01-28 19:43                             ` pktcdvd Linus Torvalds
2023-01-29 21:53                               ` pktcdvd Jens Axboe
2023-01-29 21:55                             ` pktcdvd Jens Axboe
2023-01-29 22:21                               ` pktcdvd Pali Rohár
2023-01-29 22:34                                 ` pktcdvd Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221226195206.GA2626419@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).