linux.git/fs/dcache.c, branch v2.6.24

dcache: don't expose uninitialized memory in /proc//fd/

2007-10-22T15:13:18+00:00

Well, it's not especially important that target->d_iname get the contents
of dentry->d_iname, but it's important that it get initialized with
*something*, otherwise we're just exposing some random piece of memory to
anyone who reads the link at /proc//fd/ for the deleted file, when
it's still held open by someone.

I've run a test program that copies a short (<36 character) name ontop of a
long (>=36 character) name and see that the first time I run it, without
this patch, I get unpredicatable results out of /proc//fd/.

Signed-off-by: J. Bruce Fields 
Cc: Al Viro 
Cc: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] audit: watching subtrees

2007-10-21T06:37:45+00:00

New kind of audit rule predicates: "object is visible in given subtree".
The part that can be sanely implemented, that is.  Limitations:
	* if you have hardlink from outside of tree, you'd better watch
it too (or just watch the object itself, obviously)
	* if you mount something under a watched tree, tell audit
that new chunk should be added to watched subtrees
	* if you umount something in a watched tree and it's still mounted
elsewhere, you will get matches on events happening there.  New command
tells audit to recalculate the trees, trimming such sources of false
positives.

Note that it's _not_ about path - if something mounted in several places
(multiple mount, bindings, different namespaces, etc.), the match does
_not_ depend on which one we are using for access.

Signed-off-by: Al Viro

vfs: use the predefined d_unhashed inline function instead

2007-10-17T15:43:00+00:00

Signed-off-by: Denis Cheng 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

shrink_dcache_sb speedup

2007-10-17T15:42:57+00:00

This patch makes shrink_dcache_sb consistent with dentry pruning policy.

On the first pass we iterate over dentry unused list and prepare some
dentries for removal.

However, since the existing code moves evicted dentries to the beginning of
the LRU it can happen that fresh dentries from other superblocks will be
inserted *before* our dentries.

This can result in significant slowdown of shrink_dcache_sb().  Moreover,
for virtual filesystems like unionfs which can call dput() during dentries
kill existing code results in O(n^2) complexity.

We observed 2 minutes shrink_dcache_sb() with only 35000 dentries.

To avoid this effects we propose to isolate sb dentries at the end
of LRU list.

Signed-off-by: Denis V. Lunev 
Signed-off-by: Kirill Korotaev 
Signed-off-by: Andrey Mirkin 
Cc: Neil Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

dcache: trivial comment fix

2007-10-17T15:42:57+00:00

As it stands this comment is confusing, and not quite grammatical.

Signed-off-by: J. Bruce Fields 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

clean out unused code in dentry pruning

2007-10-17T15:42:52+00:00

It looks like in the end all pruners want parents removed.

So remove unused code and function arguments.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs: remove the unused mempages parameter

2007-10-17T15:42:49+00:00

Since the mempages parameter is actually not used, they should be removed.

Now there is only files_init use the mempages parameter,

 	files_init(mempages);

but I don't think the adaptation to mempages in files_init is really
useful; and if files_init also changed to the prototype void (*func)(void),
the wrapper vfs_caches_init would also not need the mempages parameter.

Signed-off-by: Denis Cheng 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Group short-lived and reclaimable kernel allocations

2007-10-16T16:43:00+00:00

This patch marks a number of allocations that are either short-lived such as
network buffers or are reclaimable such as inode allocations.  When something
like updatedb is called, long-lived and unmovable kernel allocations tend to
be spread throughout the address space which increases fragmentation.

This patch groups these allocations together as much as possible by adding a
new MIGRATE_TYPE.  The MIGRATE_RECLAIMABLE type is for allocations that can be
reclaimed on demand, but not moved.  i.e.  they can be migrated by deleting
them and re-reading the information from elsewhere.

Signed-off-by: Mel Gorman 
Cc: Andy Whitcroft 
Cc: Christoph Lameter 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: Remove slab destructors from kmem_cache_create().

2007-07-20T01:11:58+00:00

Slab destructors were no longer supported after Christoph's
c59def9f222d44bb7e2f0a559f2906191a0862d7 change. They've been
BUGs for both slab and slub, and slob never supported them
either.

This rips out support for the dtor pointer from kmem_cache_create()
completely and fixes up every single callsite in the kernel (there were
about 224, not including the slab allocator definitions themselves,
or the documentation references).

Signed-off-by: Paul Mundt

mm: clean up and kernelify shrinker registration

2007-07-17T17:23:00+00:00

I can never remember what the function to register to receive VM pressure
is called.  I have to trace down from __alloc_pages() to find it.

It's called "set_shrinker()", and it needs Your Help.

1) Don't hide struct shrinker.  It contains no magic.
2) Don't allocate "struct shrinker".  It's not helpful.
3) Call them "register_shrinker" and "unregister_shrinker".
4) Call the function "shrink" not "shrinker".
5) Reduce the 17 lines of waffly comments to 13, but document it properly.

Signed-off-by: Rusty Russell 
Cc: David Chinner 
Cc: Trond Myklebust 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds