Re: Linux 6.2-rc1

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, Dec 26, 2022 at 11:52 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> 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]
> 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);
>       |         ^~~~~~

Well, that's unfortunate.

> 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

No, I think CONFIG_SLUB_TINY should probably have a

     depends on !COMPILE_TEST

or something like that instead.

It already has a

        depends on SLUB && EXPERT

which is basically supposed to disable it for any normal builds, but
obviously allmodconfig will enable EXPERT etc anyway.

That said, that f2fs case also sounds like this code triggers the
compiler being unhappy, so it might be worth having some clarification
from the f2fs people.

I'm not sure what triggers that problem just on powerpc, and only with
that CONFIG_SLUB_TINY option. Maybe those make_dentry_ptr_inline() and
make_dentry_ptr_block() functions don't get inlined in that case, and
that then makes gcc not see the values for those bitmap sizes?

Does changing the "inline" to "always_inline" perhaps fix the compiler
unpahhiness too?

> 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".

Yeah. PeterZ?

> 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.

Good.

> 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.

Kees? This indeed seems counter-productive..

           Linus