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;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-372-g43825cb665-fm-20230411.003-g43825cb6
Mime-Version: 1.0
Message-Id: <e033ac24-0301-4c7f-8928-b940454c0a2b@app.fastmail.com>
In-Reply-To: <CANpmjNMRQiPPqifLbzob6OjOX9O+bWhGrQunZY+TY6gj9HwGug@mail.gmail.com>
References: <20230421082026.2115712-1-arnd@kernel.org>
 <CANpmjNMRQiPPqifLbzob6OjOX9O+bWhGrQunZY+TY6gj9HwGug@mail.gmail.com>
Date:   Fri, 21 Apr 2023 16:40:33 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Marco Elver" <elver@google.com>, "Arnd Bergmann" <arnd@kernel.org>
Cc:     "Andrey Ryabinin" <ryabinin.a.a@gmail.com>,
        "Andrew Morton" <akpm@linux-foundation.org>,
        "Catalin Marinas" <catalin.marinas@arm.com>,
        "Will Deacon" <will@kernel.org>,
        "Alexander Potapenko" <glider@google.com>,
        "Andrey Konovalov" <andreyknvl@gmail.com>,
        "Dmitry Vyukov" <dvyukov@google.com>,
        "Vincenzo Frascino" <vincenzo.frascino@arm.com>,
        "Mark Rutland" <mark.rutland@arm.com>,
        "Kees Cook" <keescook@chromium.org>,
        "Ard Biesheuvel" <ardb@kernel.org>,
        "Marc Zyngier" <maz@kernel.org>,
        "Matthew Wilcox" <willy@infradead.org>,
        "Vlastimil Babka" <vbabka@suse.cz>,
        "Peter Zijlstra" <peterz@infradead.org>,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        kasan-dev@googlegroups.com, linux-mm@kvack.org
Subject: Re: [PATCH] kasan: use internal prototypes matching gcc-13 builtins
Content-Type: text/plain
Precedence: bulk

On Fri, Apr 21, 2023, at 11:19, Marco Elver wrote:
>
> Does it work with Clang?

I tested successfully with clang-16, but did not try other versions so far.

> I don't mind either way, but the custom kasan_size_t change seems to
> just be needed to workaround the subtle inconsistency in type
> definition, but in reality there should never be a problem. I'd rather
> the KASAN code just uses normal kernel types and we just make the
> compiler be quiet about it.

Let me double-check, I think I may have made a mistake here, and
using the normal ssize_t (but not size_t) just works right. It looks
like I confused the size_t definition with something else, so this
hack may not be needed after all. I've changed it again now and will
give it another overnight test run on the randconfig setup.

> To do that, another option is -Wno-builtin-declaration-mismatch for
> mm/kasan/ which just shuts up the compiler, and allows us to keep the
> code as-is. Does it have any downsides?

I think the warning is useful in principle, at least it makes it
more likely to catch bugs if the prototypes ever change, and to
validate that things like __asan_allocas_unpoison() that I mentioned
are actually intentional.

      Arnd