linux-kernel - Re: [-mm patch] UNION

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: <20070222031031.GF5867@filer.fsl.cs.sunysb.edu>
Date:	Wed, 21 Feb 2007 22:10:31 -0500
From:	Josef Sipek <jsipek@....cs.sunysb.edu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Adrian Bunk <bunk@...sta.de>, linux-kernel@...r.kernel.org,
	unionfs@...esystems.org
Subject: Re: [-mm patch] UNION_FS must depend on SLAB

On Wed, Feb 21, 2007 at 06:26:57PM -0800, Andrew Morton wrote:
> On Wed, 21 Feb 2007 21:00:39 -0500 Josef Sipek <jsipek@....cs.sunysb.edu> wrote:
> 
> > > I can't say more until I've managed to understand your description, which
> > > might take a while.
> > 
> > It is intended for reallocation of a buffer. The code in lookup.c allocates
> > some memory, and it may have to reallocate the buffer. The code tries to
> > prevent some unneeded allocations by looking at what the smallest object the
> > slabcache gives you is.
> > 
> > I hope this explains it better. There's some discussion about this in the
> > threads by Pekka Enberg.
> 
> Problem is, it doesn't seem that we'll be merging unionfs any time soon so
> we shouldn't be adding slab infrastructure on its behalf.  And I'd prefer
> not to have to carry slab changes in a filesystem tree.
> 
> Although if the changes are generally ok-looking and are compact then it'd
> be OK, but I do need to be alert for someone who comes along and uses that
> infrastructure in an unrelated patch, which has happened before.  When I
> prep the patch for an upstream merge, oops, doesn't compile any more.
 
Sounds reasonable to be weary of patches like that...
 
> So for now, it'd be best to jsut forget about the optimisation.

Well...

> How useful is it, anyway?

The code in lookup gets called frequently enough that I'm not sure. Whenever
one touches a file on a read-only branch, a copyup is done. This may have to
recreate the directory hierarchy leading up to the file - since the VFS
doesn't have such code, unionfs builds up a stack of all the path
components, and then it pops them off one at a time calling vfs_mkdir for
each. The stack creation is where we do this "reallocation."

Josef "Jeff" Sipek.

-- 
I'm somewhere between geek and normal.
		- Linus Torvalds
-
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/