linux-kernel - Re: [GIT PULL] slab updates for 6.10

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] [day] [month] [year] [list]

Date: Mon, 20 May 2024 12:18:41 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: David Rientjes <rientjes@...gle.com>, Joonsoo Kim
 <iamjoonsoo.kim@....com>, Christoph Lameter <cl@...ux.com>,
 Pekka Enberg <penberg@...nel.org>, Andrew Morton
 <akpm@...ux-foundation.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
 LKML <linux-kernel@...r.kernel.org>, patches@...ts.linux.dev,
 Roman Gushchin <roman.gushchin@...ux.dev>,
 Hyeonggon Yoo <42.hyeyoo@...il.com>,
 Chengming Zhou <chengming.zhou@...ux.dev>
Subject: Re: [GIT PULL] slab updates for 6.10

On 5/13/24 7:33 PM, Linus Torvalds wrote:
> On Thu, 9 May 2024 at 07:25, Vlastimil Babka <vbabka@...e.cz> wrote:
>>
>>   To avoid affecting fast paths with another shared counter (attempted in the
>>   past) or complex partial list traversal schemes that allow rescheduling, the
>>   chosen solution resorts to approximation - when the partial list is over
>>   10000 slabs long, we will only traverse first 5000 slabs from head and tail
>>   each and use the average of those to estimate the whole list. Both head and
>>   tail are used as the slabs near head to tend to have more free objects than
>>   the slabs towards the tail.
> 
> I suspect you could have cut this down by an order of magnitude, and
> made the limit be just 1k slabs rather than 10k slabs. Or even
> _another_ order of magnitude smaller.
> 
> Somebody was being a bit too worried about approximations, methinks -

Indeed, my focus was that we make the approximation as accurate as possible
when introducing it, to minimize the chance of possibly breaking somebody
and having to revert it. Then we can try reduce the limit once the approach
itself is established.

> but I think the real worry goes the other way, where it's practically
> so hard to even hit the approximation situation that it gets no
> testing at all.

Good point.

> IOW, I suspect it's better to be explicit about approximations, and
> have people aware of it, rather than be overly cautious and have it be
> a special case that almost never triggers in any normal loads.

OK we can reduce the limit sooner than later. As for explicit, there was an
idea that an approximated line in slabinfo would be marked, but I thought
changing the layout would be more likely to break someone parsing it, than
an unmarked approximation. We can be more explicit e.g. in the documentation
though for sure.

> But pulled.

Thanks.

> 
>               Linus