Messages in this thread | | | From | Suren Baghdasaryan <> | Date | Mon, 12 Feb 2024 18:20:13 -0800 | Subject | Re: [PATCH v3 05/35] mm: introduce slabobj_ext to support slab object extensions |
| |
On Mon, Feb 12, 2024 at 2:14 PM Kees Cook <keescook@chromium.org> wrote: > > On Mon, Feb 12, 2024 at 01:38:51PM -0800, Suren Baghdasaryan wrote: > > Currently slab pages can store only vectors of obj_cgroup pointers in > > page->memcg_data. Introduce slabobj_ext structure to allow more data > > to be stored for each slab object. Wrap obj_cgroup into slabobj_ext > > to support current functionality while allowing to extend slabobj_ext > > in the future. > > > > Signed-off-by: Suren Baghdasaryan <surenb@google.com> > > It looks like this doesn't change which buckets GFP_KERNEL_ACCOUNT comes > out of, is that correct? I'd love it if we didn't have separate buckets > so GFP_KERNEL and GFP_KERNEL_ACCOUNT came from the same pools (so that > the randomized pools would cover GFP_KERNEL_ACCOUNT ...)
This should not affect KMEM accounting in any way. We are simply changing the vector of obj_cgroup objects to hold complex objects which can contain more fields in addition to the original obj_cgroup (in our case it's the codetag reference). Unless I misunderstood your question?
> > Regardless: > > Reviewed-by: Kees Cook <keescook@chromium.org> > > -- > Kees Cook
| |