linux-kernel - Re: + fix-spellings-of-slab-allocator-section-in-init-kconfig.patch added to -mm tree

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 for Android: free password hash cracker in your pocket

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

Message-ID: <46413D6A.6000502@yahoo.com.au>
Date:	Wed, 09 May 2007 13:18:02 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Matt Mackall <mpm@...enic.com>
CC:	David Miller <davem@...emloft.net>, clameter@....com,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: + fix-spellings-of-slab-allocator-section-in-init-kconfig.patch
 added to -mm tree

Matt Mackall wrote:
> On Wed, May 09, 2007 at 12:02:29PM +1000, Nick Piggin wrote:
> 
>>BTW, we _really_ should be doing RCU properly in slob, because you
>>technically can't noop RCU on UP (even though the current users may be
>>safe...).
> 
> 
> Thanks. Hugh was pretty convinced it was unneeded:
> 
> http://marc.info/?l=linux-mm&m=116413907023393&w=2
> 
> And since I didn't care much about the SMP case, I didn't pursue it.

Sure the anonvma cache is OK on UP, but I'm just saying that in the
general case, you cannot noop RCU on UP systems.

SLAB_DESTROY_BY_RCU is quite a nice way to mitigate some RCU freeing
overheads for small objects, so I'd expect it may see wider use in
future. Maybe all those users would be fine too, but it's a bit nasty
to have already tricky RCU semantics deviate...


> This almost looks reasonable. I think HW_ALIGN | RCU is going to make
> it break though:
> 
> 
>>+	if (unlikely(c->flags & SLAB_DESTROY_BY_RCU))
>>+		b += sizeof(struct slob_rcu);
>>+
> 
> 
> That could be dealt with by putting the slob_rcu at the end of the
> object and having the RCU helper function use ->size to work backward
> to the actual pointer.

Sure, OK.


>> void kmem_cache_free(struct kmem_cache *c, void *b)
>> {
>> 	if (c->dtor)
>> 		c->dtor(b, c, 0);
> 
> 
> I think if we want RCU to actually work, we want to run ->dtor in
> __kmem_cache_free?

Yeah, thinko... thanks.


>>-	if (c->size < PAGE_SIZE)
>>-		slob_free(b, c->size);
>>-	else
>>-		free_pages((unsigned long)b, find_order(c->size));
>>+	if (unlikely(c->flags & SLAB_DESTROY_BY_RCU)) {
>>+		struct slob_rcu *slob_rcu;
>>+		b -= sizeof(struct slob_rcu);
>>+		slob_rcu = b;
>>+		slob_rcu->size = c->size;
> 
> 
> Which means just store c in the header^Wfooter, then we can retrieve the size
> and the dtor in the RCU helper.

OK, updated patch (about-to-be-tested) attached.

-- 
SUSE Labs, Novell Inc.

View attachment "slob-add-rcu.patch" of type "text/plain" (2822 bytes)