linux-toradex.git/fs/cramfs, branch v2.6.25.2 Linux kernel for Apalis and Colibri modules fs/cramfs/inode.c: replace hardcoded value with preprocessor constant 2007-10-18T21:37:29+00:00 Andi Drebes lists-receive@programmierforen.de 2007-10-18T10:06:55+00:00 4176ed593866b5e4bcf86896e0734315ad46661b 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 <lists-receive@programmierforen.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
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 <lists-receive@programmierforen.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/cramfs/inode.c: remove unused variable 2007-10-18T21:37:29+00:00 Andi Drebes lists-receive@programmierforen.de 2007-10-18T10:06:54+00:00 6bbfb0776615b3cb84ccfec8f5d6214938143b2a Remove a variable that is never read. Signed-off-by: Andi Drebes <lists-receive@programmierforen.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Remove a variable that is never read.

Signed-off-by: Andi Drebes <lists-receive@programmierforen.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
cramfs: error message about endianess 2007-10-17T15:42:53+00:00 Andi Drebes lists-receive@programmierforen.de 2007-10-17T06:27:12+00:00 ac8d35c5658377c280dc830352f66233e2f76f73 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 <lists-receive@programmierforen.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
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 <lists-receive@programmierforen.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm: make read_cache_page synchronous 2007-05-07T19:12:51+00:00 Nick Piggin npiggin@suse.de 2007-05-06T21:49:04+00:00 6fe6900e1e5b6fa9e5c59aa5061f244fe3f467e2 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 <npiggin@suse.de> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
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 <npiggin@suse.de>
Cc: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[PATCH] Mark struct super_operations const 2007-02-12T17:48:47+00:00 Josef 'Jeff' Sipek jsipek@cs.sunysb.edu 2007-02-12T08:55:41+00:00 ee9b6d61a2a43c5952eb43283f8db284a4e70b8a 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 <jsipek@cs.sunysb.edu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
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 <jsipek@cs.sunysb.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[PATCH] mark struct inode_operations const 1 2007-02-12T17:48:46+00:00 Arjan van de Ven arjan@linux.intel.com 2007-02-12T08:55:38+00:00 754661f143e70d66eae6c48532ca245aa05dec0e 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 <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
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 <arjan@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[PATCH] struct path: convert cramfs 2006-12-08T16:28:44+00:00 Josef Sipek jsipek@fsl.cs.sunysb.edu 2006-12-08T10:36:58+00:00 352d8af748a1bee0935987b811c9fc4693803d99 Signed-off-by: Josef Sipek <jsipek@fsl.cs.sunysb.edu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
Signed-off-by: Josef Sipek <jsipek@fsl.cs.sunysb.edu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] corrupted cramfs filesystems cause kernel oops 2006-12-07T16:39:36+00:00 Phillip Lougher phillip@lougher.org.uk 2006-12-07T04:37:20+00:00 8bb0269160df2a60764013994d0bc5165406cf4a 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 <phillip@lougher.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
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 <phillip@lougher.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] cramfs: make cramfs_uncompress_exit() return void 2006-09-29T16:18:20+00:00 Alexey Dobriyan adobriyan@gmail.com 2006-09-29T09:01:05+00:00 368bdb3d616fa352971f45b423ae6344715e620b It always returns 0, so relying on it is useless. The only caller isn't checking return value. In general, un-, de-, -free functions should return void. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
It always returns 0, so relying on it is useless.  The only caller isn't
checking return value.  In general, un-, de-, -free functions should return
void.

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] cramfs: rewrite init_cramfs_fs() 2006-09-29T16:18:20+00:00 Alexey Dobriyan adobriyan@gmail.com 2006-09-29T09:01:04+00:00 50d44ed009a628e6d5c784fae18ea743d7cf199a Two lines -- two bugs. :-( Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
Two lines -- two bugs. :-(

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>