From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C577C47088 for ; Wed, 26 May 2021 19:54:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 080E0613D7 for ; Wed, 26 May 2021 19:54:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 080E0613D7 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 815AE6B0036; Wed, 26 May 2021 15:54:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C53D6B006E; Wed, 26 May 2021 15:54:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 668B96B0070; Wed, 26 May 2021 15:54:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by kanga.kvack.org (Postfix) with ESMTP id 323CD6B0036 for ; Wed, 26 May 2021 15:54:26 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id CFF20BA05 for ; Wed, 26 May 2021 19:54:25 +0000 (UTC) X-FDA: 78184434090.07.6A094EE Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) by imf26.hostedemail.com (Postfix) with ESMTP id F328940B8CE8 for ; Wed, 26 May 2021 19:54:21 +0000 (UTC) Received: by mail-ot1-f53.google.com with SMTP id u25-20020a0568302319b02902ac3d54c25eso2187656ote.1 for ; Wed, 26 May 2021 12:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sv2g/1M156gg2Bg7bv3uu9uWPD2yQBzbsOC+trFxIgA=; b=J1m7oJ6QTvApTp1CR1os+2qIqfozZEnnRQ7T+rK1NZmRdnyx5nLjPGgH7OJGxfrCxA i4Pf4If6/DK0LVnjFLERFz+BAqO/il9RRErmJB7HAv627oYmixXBNcSDRIESjqWxG/F7 wTN5NfV2oLoqjw8tx0ljgIRuesYmbucTJIeCpxUr4AiMGEOGr3+sxr5WJtnZrkiEMJ6L SKSZ2JuvULM/LmYtQ4C2Nae270P/hjr1kM/XUPl9AU4WppMJCP7+Zw12ATjRXTDvN2pN YpX5PjOV0NC0OItfsWBGkLDurisI5xpkY+VpLnmoqrnkigcXKczOZpBVjrZ9XmlkDshU praw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sv2g/1M156gg2Bg7bv3uu9uWPD2yQBzbsOC+trFxIgA=; b=msqqiCLeH7uYsyBpq3Fqb31Op6gzXICKk5qfwHYl/6KVyyTwpQGf7czW6uk3+ES8jB VKkgP+FXSbIzmqr3wQ2KjgP9Ug4CLHbh7TXaB5K2ELLMjvv4llYpJepqJpI5dmI5Iqde Kcl1LJcNuyM7mYqc2i/r6AQFuVYB36ykOhFIf6SR4NJ0WB28+4fDuE2vmLuCe0KZG94h XA0ANH/u1NeZybRlFSoP2tRo2POKhpuuOnd/zUpwd7Z4onKcGd9lYjtAM1dPp6EmpiCS 39z02sRhcZ3BrdRhX58U0SEIXDvJk0zZb8zDK6Yw2PzvLRUYPt0j3QgvJu4A8sL8lTBV a+dA== X-Gm-Message-State: AOAM533XnZOp16QQPMu9nlz3D431/rF9KpPNm3BEVtkp7RYv9kZdxLcD NemRgSrzIVD6u7o/raljCogLGCDKtZZwaHKgLaoVCw== X-Google-Smtp-Source: ABdhPJzfw6c63WNBl9syS+7IPLLNfhbY+fqXceACkNoL+enrZ2arONrarqOM2USCVPQN/4a9/VgrJXKcvOC/vSXnOW0= X-Received: by 2002:a05:6830:349b:: with SMTP id c27mr2675otu.251.1622058864720; Wed, 26 May 2021 12:54:24 -0700 (PDT) MIME-Version: 1.0 References: <78af73393175c648b4eb10312825612f6e6889f6.1620849613.git.pcc@google.com> In-Reply-To: From: Marco Elver Date: Wed, 26 May 2021 21:54:13 +0200 Message-ID: Subject: Re: [PATCH v3 1/3] kasan: use separate (un)poison implementation for integrated init To: Peter Collingbourne Cc: Andrey Konovalov , Alexander Potapenko , Catalin Marinas , Vincenzo Frascino , Andrew Morton , Evgenii Stepanov , Linux Memory Management List , Linux ARM , kasan-dev Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: F328940B8CE8 Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=J1m7oJ6Q; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of elver@google.com designates 209.85.210.53 as permitted sender) smtp.mailfrom=elver@google.com X-Rspamd-Server: rspam03 X-Stat-Signature: q5a5qi4wdes6yeenmpg934ajki9uuip9 X-HE-Tag: 1622058861-796197 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 26 May 2021 at 21:28, Peter Collingbourne wrote: [...] > > > static inline bool kasan_has_integrated_init(void) > > > @@ -113,8 +113,30 @@ static inline bool kasan_has_integrated_init(void) > > > return false; > > > } > > > > > > +static __always_inline void kasan_alloc_pages(struct page *page, > > > + unsigned int order, gfp_t flags) > > > +{ > > > + /* Only available for integrated init. */ > > > + BUILD_BUG(); > > > +} > > > + > > > +static __always_inline void kasan_free_pages(struct page *page, > > > + unsigned int order) > > > +{ > > > + /* Only available for integrated init. */ > > > + BUILD_BUG(); > > > +} > > > > This *should* always work, as long as the compiler optimizes everything > > like we expect. > > Yeah, as I mentioned to Catalin on an earlier revision I'm not a fan > of relying on the compiler optimizing this away, but it looks like > we're already relying on this elsewhere in the kernel. That's true, and it's also how BUILD_BUG() works underneath (it calls a __attribute__((error(msg))) function guarded by a condition, or in this case without a condition... new code should usually use static_assert() but that's obviously not possible here). In fact, if the kernel is built without optimizations, BUILD_BUG() turns into no-ops. And just in case, I do not mind the BUILD_BUG(), because it should always work. > > But: In this case, I think this is sign that the interface design can be > > improved. Can we just make kasan_{alloc,free}_pages() return a 'bool > > __must_check' to indicate if kasan takes care of init? > > I considered a number of different approaches including something like > that before settling on the one in this patch. One consideration was > that we should avoid involving KASAN in normal execution as much as > possible, in order to make the normal code path as comprehensible as > possible. With an approach where alloc/free return a bool the reader > needs to understand what the KASAN alloc/free functions do in the > normal case. Whereas with an approach where an "accessor" function on > the KASAN side returns a bool, it's more obvious that the code has a > "normal path" and a "KASAN path", and readers who only care about the > normal path can ignore the KASAN path. > > Does that make sense? I don't feel too strongly so I can change > alloc/free to return a bool if you don't agree. If this had been considered, then that's fair. I just wanted to point it out in case it hadn't. Let's leave as-is. I also just noticed that we also pass 'init' to kasan_poison_pages(.., init) in the !kasan_has_integrated_init() case which might be confusing. Thanks, -- Marco