From: Kees Cook <keescook@chromium.org>
To: Alexander Potapenko <glider@google.com>
Cc: Zhaoyang Huang <huangzhaoyang@gmail.com>,
Matthew Wilcox <willy@infradead.org>,
"zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
ke.wang@unisoc.com, Marco Elver <elver@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Michal Hocko <mhocko@kernel.org>,
Eric Biggers <ebiggers@kernel.org>,
Mateusz Guzik <mjguzik@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH] mm: make __GFP_SKIP_ZERO visible to skip zero operation
Date: Fri, 1 Sep 2023 11:32:37 -0700 [thread overview]
Message-ID: <202309011130.7543E1DC9D@keescook> (raw)
In-Reply-To: <CAG_fn=VJrO3e9q0M6KA9nopqyDuRO4g7SBak6YptiEvzdE+nkA@mail.gmail.com>
On Fri, Sep 01, 2023 at 02:55:17PM +0200, Alexander Potapenko wrote:
> A draft implementation at
> https://github.com/ramosian-glider/linux/commit/00791be14eb1113eae615c74b652f94b5cc3c336
> (which probably does not apply anymore) may give some insight into how
> this is supposed to work.
> There's plenty of room for bikeshedding here (does the command-line
> flag opt-in or opt-out? should we use function names instead of some
> "keys"? can we allow overriding every allocation site without the need
> for alloc_pages_uninit()?), but if the overall scheme is viable I can
> probably proceed with an RFC.
This is my preferred direction to go with this idea (though I agree some
internals could be partially whitelisted: the "dup" functions need to
wipe the trailing rounded-up bucket size bytes still).
--
Kees Cook
next prev parent reply other threads:[~2023-09-01 18:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-31 10:52 [PATCH] mm: make __GFP_SKIP_ZERO visible to skip zero operation zhaoyang.huang
2023-08-31 12:16 ` Matthew Wilcox
2023-09-01 10:29 ` Zhaoyang Huang
2023-09-01 12:55 ` Alexander Potapenko
2023-09-01 18:32 ` Kees Cook [this message]
2023-09-04 7:54 ` Michal Hocko
2023-09-04 17:34 ` Linus Torvalds
2023-09-04 18:22 ` Eric Biggers
2023-09-05 2:25 ` Alistair Popple
2023-09-06 14:17 ` Alexander Potapenko
2023-09-04 7:31 ` Michal Hocko
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=202309011130.7543E1DC9D@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=dvyukov@google.com \
--cc=ebiggers@kernel.org \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=huangzhaoyang@gmail.com \
--cc=ke.wang@unisoc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mjguzik@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=zhaoyang.huang@unisoc.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.