[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72=unhDJOGTg+ja4UdVRp8sG7Wc+_rqQhvJideA=WNjbFA@mail.gmail.com>
Date: Thu, 22 Sep 2022 19:41:07 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: Vlastimil Babka <vbabka@...e.cz>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Hao Luo <haoluo@...gle.com>, Marco Elver <elver@...gle.com>,
linux-mm@...ck.org, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Alex Elder <elder@...nel.org>,
Josef Bacik <josef@...icpanda.com>,
David Sterba <dsterba@...e.com>,
Sumit Semwal <sumit.semwal@...aro.org>,
Christian König <christian.koenig@....com>,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
Daniel Micay <danielmicay@...il.com>,
Yonghong Song <yhs@...com>, Miguel Ojeda <ojeda@...nel.org>,
Feng Tang <feng.tang@...el.com>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, linux-btrfs@...r.kernel.org,
linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linaro-mm-sig@...ts.linaro.org, linux-fsdevel@...r.kernel.org,
intel-wired-lan@...ts.osuosl.org, dev@...nvswitch.org,
x86@...nel.org, linux-wireless@...r.kernel.org,
llvm@...ts.linux.dev, linux-hardening@...r.kernel.org
Subject: Re: [PATCH 11/12] slab: Remove __malloc attribute from realloc functions
On Thu, Sep 22, 2022 at 5:56 PM Kees Cook <keescook@...omium.org> wrote:
>
> I wasn't sure if this "composite macro" was sane there, especially since
> it would be using __malloc before it was defined, etc. Would you prefer
> I move it?
Hmm... On one hand, they end up being attributes, so it could make
sense to have them there (after all, the big advantage of that header
is that there is no `#ifdef` nest like in others, and that it is only
for attributes).
On the other hand, you are right that the file so far is intended to
be as simple as possible (`__always_inline` having an extra `inline`
and `fallthrough` would be closest outliers), so if we do it, I would
prefer to do so in an independent series that carries its own rationale.
So I would leave the patch as it is here.
Cheers,
Miguel
Powered by blists - more mailing lists