kernel.git/fs/cramfs, branch linux-2.6.28.y

cramfs: fix named-pipe handling

2008-08-20T22:40:32Z

After commit a97c9bf33f4612e2aed6f000f6b1d268b6814f3c (fix cramfs making duplicate entries in inode cache) in kernel 2.6.14, named-pipe on cramfs does not work properly. It seems the commit make all named-pipe on cramfs share their inode (and named-pipe buffer). Make ..._test() refuse to merge inodes with ->i_ino == 1, take inode setup back to get_cramfs_inode() and make ->drop_inode() evict ones with ->i_ino == 1 immediately. Reported-by: Atsushi Nemoto Cc: Al Viro Cc: [2.6.14 and later] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

fs: Remove unnecessary inclusions of asm/semaphore.h

2008-04-19T02:16:44Z

None of these files use any of the functionality promised by asm/semaphore.h. Signed-off-by: Matthew Wilcox

fs/cramfs/inode.c: replace hardcoded value with preprocessor constant

2007-10-18T21:37:29Z

Remove the hardcoded value 256 in fs/cramfs/inode.c and replaces it with CRAMFS_MAXPATHLEN. Tested on an i386 box. Signed-off-by: Andi Drebes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

fs/cramfs/inode.c: remove unused variable

2007-10-18T21:37:29Z

Remove a variable that is never read. Signed-off-by: Andi Drebes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

cramfs: error message about endianess

2007-10-17T15:42:53Z

The README file in the cramfs subdirectory says: "All data is currently in host-endian format; neither mkcramfs nor the kernel ever do swabbing." If somebody tries to mount a cramfs with the wrong endianess, cramfs only complains about a wrong magic but doesn't inform the user that only the endianess isn't right. The following patch adds an error message to the cramfs sources. If a user tries to mount a cramfs with the wrong endianess using the patched sources, cramfs will display the message "cramfs: wrong endianess". Signed-off-by: Andi Drebes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

mm: make read_cache_page synchronous

2007-05-07T19:12:51Z

Ensure pages are uptodate after returning from read_cache_page, which allows us to cut out most of the filesystem-internal PageUptodate calls. I didn't have a great look down the call chains, but this appears to fixes 7 possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in block2mtd. All depending on whether the filler is async and/or can return with a !uptodate page. Signed-off-by: Nick Piggin Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Mark struct super_operations const

2007-02-12T17:48:47Z

This patch is inspired by Arjan's "Patch series to mark struct file_operations and struct inode_operations const". Compile tested with gcc & sparse. Signed-off-by: Josef 'Jeff' Sipek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] mark struct inode_operations const 1

2007-02-12T17:48:46Z

Many struct inode_operations in the kernel can be "const". Marking them const moves these to the .rodata section, which avoids false sharing with potential dirty data. In addition it'll catch accidental writes at compile time to these shared resources. Signed-off-by: Arjan van de Ven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] struct path: convert cramfs

2006-12-08T16:28:44Z

Signed-off-by: Josef Sipek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] corrupted cramfs filesystems cause kernel oops

2006-12-07T16:39:36Z

Steve Grubb's fzfuzzer tool (http://people.redhat.com/sgrubb/files/ fsfuzzer-0.6.tar.gz) generates corrupt Cramfs filesystems which cause Cramfs to kernel oops in cramfs_uncompress_block(). The cause of the oops is an unchecked corrupted block length field read by cramfs_readpage(). This patch adds a sanity check to cramfs_readpage() which checks that the block length field is sensible. The (PAGE_CACHE_SIZE << 1) size check is intentional, even though the uncompressed data is not going to be larger than PAGE_CACHE_SIZE, gzip sometimes generates compressed data larger than the original source data. Mkcramfs checks that the compressed size is always less than or equal to PAGE_CACHE_SIZE << 1. Of course Cramfs could use the original uncompressed data in this case, but it doesn't. Signed-off-by: Phillip Lougher Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds