Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <abeeda98-e6ed-fb88-f838-6b61d43e07e5@suse.cz>
Date:   Mon, 26 Dec 2022 23:41:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: Linux 6.2-rc1
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>,
        Peter Zijlstra <peterz@infradead.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Kees Cook <keescook@chromium.org>,
        Max Filippov <jcmvbkbc@gmail.com>,
        kasan-dev <kasan-dev@googlegroups.com>,
        Marco Elver <elver@google.com>
References: <CAHk-=wgf929uGOVpiWALPyC7pv_9KbwB2EAvQ3C4woshZZ5zqQ@mail.gmail.com>
 <20221226195206.GA2626419@roeck-us.net>
 <CAHk-=whD1zMyt4c7g6-+tWvVweyb-6oHMT_+ZVHqe1EXwtFpCQ@mail.gmail.com>
Content-Language: en-US
From:   Vlastimil Babka <vbabka@suse.cz>
In-Reply-To: <CAHk-=whD1zMyt4c7g6-+tWvVweyb-6oHMT_+ZVHqe1EXwtFpCQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 12/26/22 21:56, Linus Torvalds 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.
> 
>> 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.

We can do that, although if things are on track to be fixed, maybe it's
unnecessary?

> 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

I think it's because e240e53ae0ab makes KASAN depend on !SLUB_TINY, because
KASAN does "select SLUB_DEBUG" which depends on !SLUB_TINY; but kconfig will
still honor the select even with dependencies unmet and only warn about it
(and the build would fail) so I prevented it this way. (maybe instead
SLUB_TINY depend on !KASAN would have worked better in retrospect?) So now
allmodconfig will have SLUB_TINY enabled and KASAN thus disabled.

On the other hand there are configs like KCSAN and KMSAN that depend on
!KASAN, so with KASAN disabled, now those become enabled. KCSAN becoming
enabled would be relevant for the xtensa problem. For the powerpc issue I'm
not sure as the macro expansion lines for include/linux/fortify-string.h in
Guenter's report make no sense in my 6.2-rc1 checkout for some reason. But
the header does test for KASAN and KMSAN at several points, to perhaps it's
also related to that?

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