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;
MIME-Version: 1.0
References: <CAHk-=wjwrqFcC9-KkfboqATYwLfJHi_8Z5mTrJh=nf8KT_SjUA@mail.gmail.com>
 <20230109174742.GA1191249@roeck-us.net>
In-Reply-To: <20230109174742.GA1191249@roeck-us.net>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 9 Jan 2023 16:18:02 -0600
Message-ID: <CAHk-=whC+YpdympyegB0Wr_0_6=LYggdabkMExRus2DtAdsv-Q@mail.gmail.com>
Subject: Re: Linux 6.2-rc3
To:     Guenter Roeck <linux@roeck-us.net>, Marco Elver <elver@google.com>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Kees Cook <kees@kernel.org>, Jaegeuk Kim <jaegeuk@kernel.org>,
        Vlastimil Babka <vbabka@suse.cz>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jan 9, 2023 at 11:47 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]

Ok, I guess we'll have to disable this gcc warning for this version
again. I don't think anybody figured out why it happens. We had
several people look at it (Kees, Vlastimil, Jaegeuk) and I think
everybody ended up going "tis looks like a compiler thing".

Does anybody remember - what was the compiler version again and what
do we need to disable?

> 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
>
> Context: CONFIG_SLUB_TINY is enabled with allmodconfig builds.
> This enables some previously disabled configurations and disables
> some previously enabled configurations.

I do think that the test code should be a lot more careful about
random things on stack.

We've had this before with the EXPECT() macros generating *much* too
much stack space, and it's not ok for test code to violate kernel
coding standards even if it might be a "odd config that isn't
realistic".

That function does some odd things, including

        typeof(observed.lines) expect;

WHAT IS THAT TYPE? It turns out that we have

  static struct {
        spinlock_t lock;
        int nlines;
        char lines[3][512];
  } observed = {

so it's basically a 1.5kB byte array.

And then des

                char tmp[2][64];

to add some more pressure. So yeah, can't blame the compiler being
stupid, this is just bad code.

This is all very much a "this needs to be fixed, or the test just
needs to be removed, because that's not acceptable".

None of this is new, but clearly it was hidden by config issues
before. Added the guilty parties.

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

Ok, PeterZ has been off due to the holidays, but seems back. I agree,
that outer 'struct' should obviously be 'union', but let's make the
guilty party (ie Peter) fix it up.

             Linus