linux/fs, branch v2.6.20-rc4

Revert "[PATCH] binfmt_elf: randomize PIE binaries (2nd try)"

2007-01-06T21:28:21Z

This reverts commit 59287c0913cc9a6c75712a775f6c1c1ef418ef3b. Hugh Dickins reports that it causes random failures on x86 with SuSE 10.2, and points out "Isn't that randomization, anywhere from 0x10000 to ELF_ET_DYN_BASE, sure to place the ET_DYN from time to time just where the comment says it's trying to avoid? I assume that somehow results in the error reported." (where the comment in question is the existing comment in the source code about mmap/brk clashes). Suggested-by: Hugh Dickins Acked-by: Marcus Meissner Cc: Andrew Morton Cc: Andi Kleen Cc: Ingo Molnar Cc: Dave Jones Cc: Arjan van de Ven Signed-off-by: Linus Torvalds

[PATCH] fix garbage instead of zeroes in UFS

2007-01-06T07:55:29Z

Looks like this is the problem, which point Al Viro some time ago: ufs's get_block callback allocates 16k of disk at a time, and links that entire 16k into the file's metadata. But because get_block is called for only a single buffer_head (a 2k buffer_head in this case?) we are only able to tell the VFS that this 2k is buffer_new(). So when ufs_getfrag_block() is later called to map some more data in the file, and when that data resides within the remaining 14k of this fragment, ufs_getfrag_block() will incorrectly return a !buffer_new() buffer_head. I don't see _right_ way to do nullification of whole block, if use inode page cache, some pages may be outside of inode limits (inode size), and will be lost; if use blockdev page cache it is possible to zero real data, if later inode page cache will be used. The simpliest way, as can I see usage of block device page cache, but not only mark dirty, but also sync it during "nullification". I use my simple tests collection, which I used for check that create,open,write,read,close works on ufs, and I see that this patch makes ufs code 18% slower then before. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] fix memory corruption from misinterpreted bad_inode_ops return values

2007-01-06T07:55:23Z

CVE-2006-5753 is for a case where an inode can be marked bad, switching the ops to bad_inode_ops, which are all connected as: static int return_EIO(void) { return -EIO; } #define EIO_ERROR ((void *) (return_EIO)) static struct inode_operations bad_inode_ops = { .create = bad_inode_create ...etc... The problem here is that the void cast causes return types to not be promoted, and for ops such as listxattr which expect more than 32 bits of return value, the 32-bit -EIO is interpreted as a large positive 64-bit number, i.e. 0x00000000fffffffa instead of 0xfffffffa. This goes particularly badly when the return value is taken as a number of bytes to copy into, say, a user's buffer for example... I originally had coded up the fix by creating a return_EIO_ macro for each return type, like this: static int return_EIO_int(void) { return -EIO; } #define EIO_ERROR_INT ((void *) (return_EIO_int)) static struct inode_operations bad_inode_ops = { .create = EIO_ERROR_INT, ...etc... but Al felt that it was probably better to create an EIO-returner for each actual op signature. Since so few ops share a signature, I just went ahead & created an EIO function for each individual file & inode op that returns a value. Signed-off-by: Eric Sandeen Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] adfs: fix filename handling

2007-01-06T07:55:22Z

Fix filenames on adfs discs being terminated at the first character greater than 128 (adfs filenames are Latin 1). I saw this problem when using a loopback adfs image on a 2.6.17-rc5 x86_64 machine, and the patch fixed it there. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2

2006-12-30T20:02:53Z

* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2: ocfs2: export heartbeat thread pid via configfs ocfs2: always unmap in ocfs2_data_convert_worker() ocfs2: ignore NULL vfsmnt in ocfs2_should_update_atime() ocfs2: Allow direct I/O read past end of file ocfs2: don't print error in ocfs2_permission()

[PATCH] ramfs breaks without CONFIG_BLOCK

2006-12-30T18:56:42Z

ramfs doesn't provide the .set_dirty_page a_op, and when the BLOCK layer is not configured in, 'set_page_dirty' makes a call via a NULL pointer. Signed-off-by: Dimitri Gorokhovik Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[PATCH] Fix lock inversion aio_kick_handler()

2006-12-30T18:55:54Z

lockdep found a AB BC CA lock inversion in retry-based AIO: 1) The task struct's alloc_lock (A) is acquired in process context with interrupts enabled. An interrupt might arrive and call wake_up() which grabs the wait queue's q->lock (B). 2) When performing retry-based AIO the AIO core registers aio_wake_function() as the wake funtion for iocb->ki_wait. It is called with the wait queue's q->lock (B) held and then tries to add the iocb to the run list after acquiring the ctx_lock (C). 3) aio_kick_handler() holds the ctx_lock (C) while acquiring the alloc_lock (A) via lock_task() and unuse_mm(). Lockdep emits a warning saying that we're trying to connect the irq-safe q->lock to the irq-unsafe alloc_lock via ctx_lock. This fixes the inversion by calling unuse_mm() in the AIO kick handing path after we've released the ctx_lock. As Ben LaHaise pointed out __put_ioctx could set ctx->mm to NULL, so we must only access ctx->mm while we have the lock. Signed-off-by: Zach Brown Signed-off-by: Suparna Bhattacharya Acked-by: Benjamin LaHaise Cc: "Chen, Kenneth W" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

ocfs2: export heartbeat thread pid via configfs

2006-12-29T00:40:32Z

The patch allows the ocfs2 heartbeat thread to prioritize I/O which may help cut down on spurious fencing. Most of this will be in the tools - we can have a pid configfs attribute and let userspace (ocfs2_hb_ctl) calls the ioprio_set syscall after starting heartbeat, but only cfq scheduler supports I/O priorities now. Signed-off-by: Zhen Wei Signed-off-by: Mark Fasheh

ocfs2: always unmap in ocfs2_data_convert_worker()

2006-12-29T00:38:59Z

Mmap-heavy clustered workloads were sometimes finding stale data on mmap reads. The solution is to call unmap_mapping_range() on any down convert of a data lock. Signed-off-by: Mark Fasheh

ocfs2: ignore NULL vfsmnt in ocfs2_should_update_atime()

2006-12-29T00:38:32Z

This can come from NFSD. Signed-off-by: Mark Fasheh