lkml.org 
[lkml]   [2022]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 6.2-rc1
On December 26, 2022 12:56:29 PM PST, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>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.

I'll look into this.

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

Hrm, that is not supposed to take THAT long... But yes a cross-arxh qemu run would be slow. :(

The changes there were to help find any future memcpy problem (like seen while porting the i386 memcpy asm...) I'll try to get this reduced. Dropping the test isn't so great. :)



--
Kees Cook

\
 
 \ /
  Last update: 2023-03-26 23:21    [W:0.174 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site