From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: "Vlastimil Babka" <vbabka@suse.cz>,
"Pekka Enberg" <penberg@kernel.org>,
"David Rientjes" <rientjes@google.com>,
"Joonsoo Kim" <iamjoonsoo.kim@lge.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Hao Luo" <haoluo@google.com>, "Marco Elver" <elver@google.com>,
linux-mm@kvack.org, "David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Alex Elder" <elder@kernel.org>,
"Josef Bacik" <josef@toxicpanda.com>,
"David Sterba" <dsterba@suse.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
"Jesse Brandeburg" <jesse.brandeburg@intel.com>,
"Daniel Micay" <danielmicay@gmail.com>,
"Yonghong Song" <yhs@fb.com>, "Miguel Ojeda" <ojeda@kernel.org>,
"Feng Tang" <feng.tang@intel.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
linux-fsdevel@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
dev@openvswitch.org, x86@kernel.org,
linux-wireless@vger.kernel.org, llvm@lists.linux.dev,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH 11/12] slab: Remove __malloc attribute from realloc functions
Date: Thu, 22 Sep 2022 19:41:07 +0200 [thread overview]
Message-ID: <CANiq72=unhDJOGTg+ja4UdVRp8sG7Wc+_rqQhvJideA=WNjbFA@mail.gmail.com> (raw)
In-Reply-To: <202209220855.B8DA16E@keescook>
On Thu, Sep 22, 2022 at 5:56 PM Kees Cook <keescook@chromium.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
next prev parent reply other threads:[~2022-09-22 17:41 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-22 3:10 [PATCH 00/12] slab: Introduce kmalloc_size_roundup() Kees Cook
2022-09-22 3:10 ` [PATCH 01/12] " Kees Cook
2022-09-22 11:12 ` Hyeonggon Yoo
2022-09-23 1:17 ` Feng Tang
2022-09-23 18:50 ` Kees Cook
2022-09-22 3:10 ` [PATCH 02/12] skbuff: Proactively round up to kmalloc bucket size Kees Cook
2022-09-22 19:40 ` Jakub Kicinski
2022-09-22 3:10 ` [PATCH 03/12] net: ipa: " Kees Cook
2022-09-22 13:45 ` Alex Elder
2022-09-22 15:57 ` Kees Cook
2022-09-22 3:10 ` [PATCH 04/12] btrfs: send: " Kees Cook
2022-09-22 13:30 ` David Sterba
2022-09-22 3:10 ` [PATCH 05/12] dma-buf: " Kees Cook
2022-09-22 3:10 ` [PATCH 06/12] coredump: " Kees Cook
2022-09-22 3:10 ` [PATCH 07/12] igb: " Kees Cook
2022-09-22 15:56 ` Ruhl, Michael J
2022-09-22 16:00 ` Kees Cook
2022-09-22 3:10 ` [PATCH 08/12] openvswitch: " Kees Cook
2022-09-22 3:10 ` [PATCH 09/12] x86/microcode/AMD: Track patch allocation size explicitly Kees Cook
2022-09-22 3:10 ` [PATCH 10/12] iwlwifi: Track scan_cmd " Kees Cook
2022-09-22 4:18 ` Kalle Valo
2022-09-22 5:26 ` Kees Cook
2022-09-22 3:10 ` [PATCH 11/12] slab: Remove __malloc attribute from realloc functions Kees Cook
2022-09-22 9:23 ` Miguel Ojeda
2022-09-22 15:56 ` Kees Cook
2022-09-22 17:41 ` Miguel Ojeda [this message]
2022-09-22 3:10 ` [PATCH 12/12] slab: Restore __alloc_size attribute to __kmalloc_track_caller Kees Cook
2022-09-22 7:10 ` [PATCH 00/12] slab: Introduce kmalloc_size_roundup() Christian König
2022-09-22 15:55 ` Kees Cook
2022-09-22 21:05 ` Vlastimil Babka
2022-09-22 21:49 ` Kees Cook
2022-09-23 9:07 ` Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANiq72=unhDJOGTg+ja4UdVRp8sG7Wc+_rqQhvJideA=WNjbFA@mail.gmail.com' \
--to=miguel.ojeda.sandonis@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=christian.koenig@amd.com \
--cc=danielmicay@gmail.com \
--cc=davem@davemloft.net \
--cc=dev@openvswitch.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=dsterba@suse.com \
--cc=edumazet@google.com \
--cc=elder@kernel.org \
--cc=elver@google.com \
--cc=feng.tang@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=haoluo@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=josef@toxicpanda.com \
--cc=keescook@chromium.org \
--cc=kuba@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-wireless@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=ndesaulniers@google.com \
--cc=netdev@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=pabeni@redhat.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=sumit.semwal@linaro.org \
--cc=vbabka@suse.cz \
--cc=x86@kernel.org \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).