linux-kernel - Re: [PATCH 1/2] mm: slub: allocate slab object extensions non-contiguously

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <l7sk6ga4ckxo27wfbkqrmbu6yfu3ia4sttkhki6hh2omjbxkxv@fxwjog4jmjwu>
Date: Tue, 20 May 2025 13:25:52 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: Usama Arif <usamaarif642@...il.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, hannes@...xchg.org, shakeel.butt@...ux.dev, vlad.wing@...il.com, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCH 1/2] mm: slub: allocate slab object extensions
 non-contiguously

On Tue, May 20, 2025 at 10:20:23AM -0700, Suren Baghdasaryan wrote:
> On Tue, May 20, 2025 at 9:41 AM Kent Overstreet
> <kent.overstreet@...ux.dev> wrote:
> I see your point. One case we would want to use vmalloc is if the
> allocation is sizable (multiple pages), so failing it does not mean
> critical memory pressure level yet. I don't think today's extension
> vectors would be large enough to span multiple pages. That would
> require a rather large obj_per_slab and in most cases I think this
> change would not affect current behavior, the allocations will be
> smaller than PAGE_SIZE and kvmalloc will fail anyway.
> I guess the question is whether we want to fail if allocation size is
> higher than PAGE_SIZE but less than PAGE_ALLOC_COSTLY_ORDER. Failing
> that I think is reasonable and I don't think any extension vector will
> be large enough to reach PAGE_ALLOC_COSTLY_ORDER. So, I'm ok with
> dropping this part of the patchset.

Johannes raisess more pertinent points, so I think vmalloc allocation is
out.

If it turns out that extension vector allocation failures do cause real
problems (not for memory allocation profiling, but maybe someone is
depending on memcg being precise), I think it would acceptable to dip
into reserves for them, since they're a small fraction of the slabs
themselves.

With the caveat that we'd need to look at how the reserves are sized, to
make sure we're not running them empty and causing new problems
elsewhere.

But just failing the allocation should probably be the default approach
here.