[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202403251609.1F681B5D@keescook>
Date: Mon, 25 Mar 2024 16:13:56 -0700
From: Kees Cook <keescook@...omium.org>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Vlastimil Babka <vbabka@...e.cz>, Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Hyeonggon Yoo <42.hyeyoo@...il.com>, linux-mm@...ck.org,
"GONG, Ruiqi" <gongruiqi@...weicloud.com>,
Xiu Jianfeng <xiujianfeng@...wei.com>,
Suren Baghdasaryan <surenb@...gle.com>,
Jann Horn <jannh@...gle.com>, Matteo Rizzo <matteorizzo@...gle.com>,
linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2 4/9] slab: Introduce kmem_buckets_create()
On Mon, Mar 25, 2024 at 05:49:49PM -0400, Kent Overstreet wrote:
> The codetags are in their own dedicated elf sections already, so if you
> put the kmem_buckets in the codetag the entire elf section can be
> discarded if it's not in use.
Gotcha. Yeah, sounds good. Once codetags and this series land, I can
start working on making the per-site series.
> "usercopy window"? You're now annotating which data can be copied to
> userspace?
Hm? Yes. That's been there for over 7 years. :) It's just that it was only
meaningful for kmem_cache_create() users, since the proposed GFP_USERCOPY
for kmalloc() never landed[1].
-Kees
[1] https://lore.kernel.org/lkml/1497915397-93805-23-git-send-email-keescook@chromium.org/
--
Kees Cook
Powered by blists - more mailing lists