linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.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 13:03:59 -0800	[thread overview]
Message-ID: <DA632860-284E-4923-8863-9D2745DD289E@kernel.org> (raw)
In-Reply-To: <CAHk-=whD1zMyt4c7g6-+tWvVweyb-6oHMT_+ZVHqe1EXwtFpCQ@mail.gmail.com>

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

  reply	other threads:[~2022-12-26 21:04 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
2022-12-26 20:56   ` Linus Torvalds
2022-12-26 21:03     ` Kees Cook [this message]
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=DA632860-284E-4923-8863-9D2745DD289E@kernel.org \
    --to=kees@kernel.org \
    --cc=chao@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --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).