From: Linus Torvalds <torvalds@linux-foundation.org>
To: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
apw@canonical.com, Christoph Lameter <cl@linux.com>,
Daniel Micay <danielmicay@gmail.com>,
Dennis Zhou <dennis@kernel.org>,
dwaipayanray1@gmail.com, Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Joe Perches <joe@perches.com>, Linux-MM <linux-mm@kvack.org>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>,
mm-commits@vger.kernel.org,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Miguel Ojeda <ojeda@kernel.org>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>, Tejun Heo <tj@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [patch 9/9] mm/vmalloc: add __alloc_size attributes for better bounds checking
Date: Fri, 10 Sep 2021 12:17:40 -0700 [thread overview]
Message-ID: <CAHk-=whHPPKunYcDmSAJ4--o7VddZW-SWmMqQkiYwA_kEyQVUQ@mail.gmail.com> (raw)
In-Reply-To: <202109101138.53FCADF5C@keescook>
On Fri, Sep 10, 2021 at 11:43 AM Kees Cook <keescook@chromium.org> wrote:
>
> I had originally set out to do that, but the problem with merging with
> __malloc is the bit in the docs about "and that the memory has undefined
> content". So we can't do that for kmalloc() in the face of GFP_ZERO, as
> well as a bunch of other helpers. I always get suspicious about "this
> will improve optimization because we depend on claiming something is
> 'undefined'". :|
Oh, I had entirely missed that historical subtlety of __malloc.
Yeah, that would have been absolutely horrible. But it's not actually
really true.
It seems that the gcc people actually realized the problem, and fixed
the documentation:
"Attribute malloc indicates that a function is malloc-like, i.e.,
that the pointer P returned by the function cannot alias any other
pointer valid when the function returns, and moreover no pointers to
valid objects occur in any storage addressed by P. In addition, the
GCC predicts that a function with the attribute returns non-null in
most cases"
IOW, it is purely about aliasing guarantees. Basically the guarantee
is that the memory that a "malloc" function returns can not alias
(directly or indirectly) any other allocations.
See
https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes
So I think it's ok, and your reaction was entirely correct, but came
from looking at old documentation.
Linus
next prev parent reply other threads:[~2021-09-10 19:18 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-10 3:09 incoming Andrew Morton
2021-09-10 3:10 ` [patch 1/9] mm: move kvmalloc-related functions to slab.h Andrew Morton
2021-09-10 3:10 ` [patch 2/9] rapidio: avoid bogus __alloc_size warning Andrew Morton
2021-09-10 3:10 ` [patch 3/9] Compiler Attributes: add __alloc_size() for better bounds checking Andrew Morton
2021-09-10 3:10 ` [patch 4/9] checkpatch: add __alloc_size() to known $Attribute Andrew Morton
2021-09-10 3:10 ` [patch 5/9] slab: clean up function declarations Andrew Morton
2021-09-10 3:10 ` [patch 6/9] slab: add __alloc_size attributes for better bounds checking Andrew Morton
2021-09-10 3:10 ` [patch 7/9] mm/page_alloc: " Andrew Morton
2021-09-10 3:10 ` [patch 8/9] percpu: " Andrew Morton
2021-09-10 3:10 ` [patch 9/9] mm/vmalloc: " Andrew Morton
2021-09-10 17:23 ` Linus Torvalds
2021-09-10 18:43 ` Kees Cook
2021-09-10 19:17 ` Linus Torvalds [this message]
2021-09-10 19:32 ` Kees Cook
2021-09-10 19:49 ` Nick Desaulniers
2021-09-10 20:16 ` Linus Torvalds
2021-09-10 20:47 ` Kees Cook
2021-09-10 20:58 ` Nick Desaulniers
2021-09-10 21:07 ` Kees Cook
2021-09-11 5:29 ` Joe Perches
2021-09-21 23:37 ` Kees Cook
2021-09-21 23:45 ` Joe Perches
2021-09-22 2:25 ` function prototype element ordering Kees Cook
2021-09-22 4:24 ` Joe Perches
2021-09-24 19:43 ` Kees Cook
2021-09-22 7:24 ` Alexey Dobriyan
2021-09-22 8:51 ` Joe Perches
2021-09-22 10:45 ` Alexey Dobriyan
2021-09-22 11:19 ` Jani Nikula
2021-09-22 21:15 ` Linus Torvalds
2021-09-23 5:10 ` Joe Perches
2021-09-25 19:40 ` David Laight
2021-09-26 21:03 ` Linus Torvalds
2021-09-27 8:21 ` David Laight
2021-09-27 9:22 ` Willy Tarreau
2021-09-10 17:11 ` incoming Kees Cook
2021-09-10 20:13 ` incoming Kees Cook
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='CAHk-=whHPPKunYcDmSAJ4--o7VddZW-SWmMqQkiYwA_kEyQVUQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=apw@canonical.com \
--cc=cl@linux.com \
--cc=danielmicay@gmail.com \
--cc=dennis@kernel.org \
--cc=dwaipayanray1@gmail.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=joe@perches.com \
--cc=keescook@chromium.org \
--cc=linux-mm@kvack.org \
--cc=lukas.bulwahn@gmail.com \
--cc=mm-commits@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=ojeda@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=tj@kernel.org \
--cc=vbabka@suse.cz \
/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).