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: <Pine.LNX.4.64.0810221416130.26639@quilx.com>
Date:	Wed, 22 Oct 2008 14:28:57 -0700 (PDT)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Miklos Szeredi <miklos@...redi.hu>
cc:	penberg@...helsinki.fi, nickpiggin@...oo.com.au, hugh@...itas.com,
	linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: SLUB defrag pull request?

On Wed, 22 Oct 2008, Miklos Szeredi wrote:

>> Actually, when debugging is enabled, it's customary to poison the
>> object, for example (see free_debug_processing() in mm/slub.c). So we
>> really can't "easily ensure" that in the allocator unless we by-pass
>> all the current debugging code.

Plus the allocator may be reusing parts of the freed object for a freelist 
etc even if the object is not poisoned.

> Thank you, that does actually answer my question.  I would still think
> it's a good sacrifice to no let the dentries be poisoned for the sake
> of a simpler dentry defragmenter.

You can simplify defrag by not doing anything in the get() method. That 
means some of the objects passed to the kick() method may be already have 
been freed in the interim.

The kick method then must be able to determine if the object has already 
been freed (or is undergoing freeing) by inspecting the object contents 
(allocations are held off until kick() is complete). It then needs to free 
only the objects that are still allocated.

That way you could get to a one stage system.... If the dentry code can 
give us that then the approach would become much simpler.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ