linux-toradex.git/fs, branch v2.6.32.31

ldm: corrupted partition table can cause kernel oops

2011-03-02T14:47:05+00:00

commit 294f6cf48666825d23c9372ef37631232746e40d upstream.

The kernel automatically evaluates partition tables of storage devices.
The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains
a bug that causes a kernel oops on certain corrupted LDM partitions.  A
kernel subsystem seems to crash, because, after the oops, the kernel no
longer recognizes newly connected storage devices.

The patch changes ldm_parse_vmdb() to Validate the value of vblk_size.

Signed-off-by: Timo Warns 
Cc: Eugene Teo 
Acked-by: Richard Russon 
Cc: Harvey Harrison 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

epoll: prevent creating circular epoll structures

2011-03-02T14:47:04+00:00

commit 22bacca48a1755f79b7e0f192ddb9fbb7fc6e64e upstream.

In several places, an epoll fd can call another file's ->f_op->poll()
method with ep->mtx held.  This is in general unsafe, because that other
file could itself be an epoll fd that contains the original epoll fd.

The code defends against this possibility in its own ->poll() method using
ep_call_nested, but there are several other unsafe calls to ->poll
elsewhere that can be made to deadlock.  For example, the following simple
program causes the call in ep_insert recursively call the original fd's
->poll, leading to deadlock:

 #include 
 #include 

 int main(void) {
     int e1, e2, p[2];
     struct epoll_event evt = {
         .events = EPOLLIN
     };

     e1 = epoll_create(1);
     e2 = epoll_create(2);
     pipe(p);

     epoll_ctl(e2, EPOLL_CTL_ADD, e1, &evt);
     epoll_ctl(e1, EPOLL_CTL_ADD, p[0], &evt);
     write(p[1], p, sizeof p);
     epoll_ctl(e1, EPOLL_CTL_ADD, e2, &evt);

     return 0;
 }

On insertion, check whether the inserted file is itself a struct epoll,
and if so, do a recursive walk to detect whether inserting this file would
create a loop of epoll structures, which could lead to deadlock.

[nelhage@ksplice.com: Use epmutex to serialize concurrent inserts]
Signed-off-by: Davide Libenzi 
Signed-off-by: Nelson Elhage 
Reported-by: Nelson Elhage 
Tested-by: Nelson Elhage 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: Copy up lower inode attrs in getattr

2011-03-02T14:46:53+00:00

commit 55f9cf6bbaa682958a7dd2755f883b768270c3ce upstream.

The lower filesystem may do some type of inode revalidation during a
getattr call. eCryptfs should take advantage of that by copying the
lower inode attributes to the eCryptfs inode after a call to
vfs_getattr() on the lower inode.

I originally wrote this fix while working on eCryptfs on nfsv3 support,
but discovered it also fixed an eCryptfs on ext4 nanosecond timestamp
bug that was reported.

https://bugs.launchpad.net/bugs/613873

Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman

fs/partitions: Validate map_count in Mac partition tables

2011-03-02T14:46:50+00:00

commit fa7ea87a057958a8b7926c1a60a3ca6d696328ed upstream.

Validate number of blocks in map and remove redundant variable.

Signed-off-by: Timo Warns 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

s390: remove task_show_regs

2011-03-02T14:46:49+00:00

commit 261cd298a8c363d7985e3482946edb4bfedacf98 upstream.

task_show_regs used to be a debugging aid in the early bringup days
of Linux on s390. /proc//status is a world readable file, it
is not a good idea to show the registers of a process. The only
correct fix is to remove task_show_regs.

Reported-by: Al Viro 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

xfs: fix untrusted inode number lookup

2011-03-02T14:46:48+00:00

Upstream commit: 4536f2ad8b330453d7ebec0746c4374eadd649b1

Commit 7124fe0a5b619d65b739477b3b55a20bf805b06d ("xfs: validate untrusted inode
numbers during lookup") changes the inode lookup code to do btree lookups for
untrusted inode numbers. This change made an invalid assumption about the
alignment of inodes and hence incorrectly calculated the first inode in the
cluster. As a result, some inode numbers were being incorrectly considered
invalid when they were actually valid.

The issue was not picked up by the xfstests suite because it always runs fsr
and dump (the two utilities that utilise the bulkstat interface) on cache hot
inodes and hence the lookup code in the cold cache path was not sufficiently
exercised to uncover this intermittent problem.

Fix the issue by relaxing the btree lookup criteria and then checking if the
record returned contains the inode number we are lookup for. If it we get an
incorrect record, then the inode number is invalid.

Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
[dannf: Backported to 2.6.32.y]
Cc: dann frazier 
Signed-off-by: Greg Kroah-Hartman

xfs: remove block number from inode lookup code

2011-03-02T14:46:48+00:00

Upstream commit: 7b6259e7a83647948fa33a736cc832310c8d85aa

The block number comes from bulkstat based inode lookups to shortcut
the mapping calculations. We ar enot able to trust anything from
bulkstat, so drop the block number as well so that the correct
lookups and mappings are always done.

Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
[dannf: Backported to 2.6.32.y]
Cc: dann frazier 
Signed-off-by: Greg Kroah-Hartman

xfs: rename XFS_IGET_BULKSTAT to XFS_IGET_UNTRUSTED

2011-03-02T14:46:47+00:00

Upstream commit: 1920779e67cbf5ea8afef317777c5bf2b8096188

Inode numbers may come from somewhere external to the filesystem
(e.g. file handles, bulkstat information) and so are inherently
untrusted. Rename the flag we use for these lookups to make it
obvious we are doing a lookup of an untrusted inode number and need
to verify it completely before trying to read it from disk.

Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
[dannf: backported to 2.6.32.y]
Cc: dann frazier 
Signed-off-by: Greg Kroah-Hartman

xfs: validate untrusted inode numbers during lookup

2011-03-02T14:46:47+00:00

Upstream commit: 7124fe0a5b619d65b739477b3b55a20bf805b06d

When we decode a handle or do a bulkstat lookup, we are using an
inode number we cannot trust to be valid. If we are deleting inode
chunks from disk (default noikeep mode), then we cannot trust the on
disk inode buffer for any given inode number to correctly reflect
whether the inode has been unlinked as the di_mode nor the
generation number may have been updated on disk.

This is due to the fact that when we delete an inode chunk, we do
not write the clusters back to disk when they are removed - instead
we mark them stale to avoid them being written back potentially over
the top of something that has been subsequently allocated at that
location. The result is that we can have locations of disk that look
like they contain valid inodes but in reality do not. Hence we
cannot simply convert the inode number to a block number and read
the location from disk to determine if the inode is valid or not.

As a result, and XFS_IGET_BULKSTAT lookup needs to actually look the
inode up in the inode allocation btree to determine if the inode
number is valid or not.

It should be noted even on ikeep filesystems, there is the
possibility that blocks on disk may look like valid inode clusters.
e.g. if there are filesystem images hosted on the filesystem. Hence
even for ikeep filesystems we really need to validate that the inode
number is valid before issuing the inode buffer read.

Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
[dannf: backported to 2.6.32.y]
Cc: dann frazier 
Signed-off-by: Greg Kroah-Hartman

xfs: always use iget in bulkstat

2011-03-02T14:46:46+00:00

Upstream commit: 7dce11dbac54fce777eea0f5fb25b2694ccd7900

The non-coherent bulkstat versionsthat look directly at the inode
buffers causes various problems with performance optimizations that
make increased use of just logging inodes.  This patch makes bulkstat
always use iget, which should be fast enough for normal use with the
radix-tree based inode cache introduced a while ago.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Dave Chinner 
[dannf: backported to 2.6.32.y]
Cc: dann frazier 
Signed-off-by: Greg Kroah-Hartman