Commit Graph

106 Commits

Author SHA1 Message Date
Arjan van de Ven
4b6f5d20b0 [PATCH] Make most file operations structs in fs/ const
This is a conversion to make the various file_operations structs in fs/
const.  Basically a regexp job, with a few manual fixups

The goal is both to increase correctness (harder to accidentally write to
shared datastructures) and reducing the false sharing of cachelines with
things that get dirty in .data (while .rodata is nicely read only and thus
cache clean)

Signed-off-by: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-28 09:16:06 -08:00
Ingo Molnar
353ab6e97b [PATCH] sem2mutex: fs/
Semaphore to mutex conversion.

The conversion was generated via scripts, and the result was validated
automatically via a script as well.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Eric Van Hensbergen <ericvh@ericvh.myip.org>
Cc: Robert Love <rml@tech9.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Neil Brown <neilb@cse.unsw.edu.au>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Dave Kleikamp <shaggy@austin.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-26 08:56:55 -08:00
Dave Johnson
ff3aea0e68 [PATCH] cramfs mounts provide corrupted content since 2.6.15
Fix handling of cramfs images created by util-linux containing empty
regular files.  Images created by cramfstools 1.x were ok.

Fill out inode contents in cramfs_iget5_set() instead of get_cramfs_inode()
to prevent issues if cramfs_iget5_test() is called with I_LOCK|I_NEW still
set.

Signed-off-by: Dave Johnson <djohnson+linux-kernel@sw.starentnetworks.com>
Cc: Olaf Hering <olh@suse.de>
Cc: Chris Mason <mason@suse.com>
Cc: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-06 18:40:43 -08:00
Adrian Bunk
e711700a0e [PATCH] fs/cramfs/uncompress.c should #include <linux/cramfs_fs.h>
Every file should #include the header with the prototypes of the global
functions it is offering.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-10 10:06:35 -07:00
Dave Johnson
a97c9bf33f [PATCH] fix cramfs making duplicate entries in inode cache
Every time cramfs_lookup() is called to lookup and inode for a dentry,
get_cramfs_inode() will allocate a new inode without checking to see if that
inode already exists in the inode cache.

This is fine the first time, but if the dentry cache entry(ies) associated
with that inode are aged out, but the inode entry is not aged out (which can
be quite common if the inode has buffer cache linked to it), cramfs_lookup()
will be called again and another inode will be allocated and added to the
inode cache creating a duplicate in the inode cache.

The big issue here is that the buffers associated with each inode cache entry
are not shared between the duplicates!

The older inode entries are now orphaned as no dentry points to it and won't
be freed until the buffer cache assoicated with them are first freed.  The
newest entry will have to create all new buffer cache for each part of its
file as the old buffer cache is now orphaned as well.

Patch below fixes this by making get_cramfs_inode() use the inode cache before
blindly creating a new entry every time.  This eliminates the duplicate inodes
and duplicate buffer cache.

Cc: Phillip Lougher <phillip@lougher.demon.co.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07 16:57:33 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00