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

XFS: set b_error from bio error in xfs_buf_bio_end_io

2009-02-12T17:31:11+00:00

commit cfbe52672fbc6f333892e8dde82c35e0a76aa5f5 upstream.

Preserve any error returned by the bio layer.

Reviewed-by: Eric Sandeen 
Reviewed-by: Tim Shimmin 
Signed-off-by: Lachlan McIlroy 
Cc: Neil Brown 
Signed-off-by: Greg Kroah-Hartman

elf core dump: fix get_user use

2009-02-12T17:31:11+00:00

commit 92dc07b1f988e8c237a38e23be660b9b8533e6fd upstream.

The elf_core_dump() code does its work with set_fs(KERNEL_DS) in force,
so vma_dump_size() needs to switch back with set_fs(USER_DS) to safely
use get_user() for a normal user-space address.

Checking for VM_READ optimizes out the case where get_user() would fail
anyway.  The vm_file check here was already superfluous given the control
flow earlier in the function, so that is a cleanup/optimization unrelated
to other changes but an obvious and trivial one.

Reported-by: Gerald Schaefer 
Signed-off-by: Roland McGrath 
Signed-off-by: Greg Kroah-Hartman

seq_file: fix big-enough lseek() + read()

2009-02-12T17:31:11+00:00

commit f01d1d546abb2f4028b5299092f529eefb01253a upstream.

lseek() further than length of the file will leave stale ->index
(second-to-last during iteration). Next seq_read() will not notice
that ->f_pos is big enough to return 0, but will print last item
as if ->f_pos is pointing to it.

Introduced in commit cb510b8172602a66467f3551b4be1911f5a7c8c2
aka "seq_file: more atomicity in traverse()".

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

seq_file: move traverse so it can be used from seq_read

2009-02-12T17:31:10+00:00

commit 33da8892a2f9e7d4b2d9a35fc80833ba2d2b1aa6 upstream.

In 2.6.25 some /proc files were converted to use the seq_file
infrastructure.  But seq_files do not correctly support pread(), which
broke some usersapce applications.

To handle pread correctly we can't assume that f_pos is where we left it
in seq_read.  So move traverse() so that we can eventually use it in
seq_read and do thus some day support pread().

Signed-off-by: Eric Biederman 
Cc: Paul Turner 
Cc: Alexey Dobriyan 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

dlm: initialize file_lock struct in GETLK before copying conflicting lock

2009-02-06T22:00:45+00:00

commit 20d5a39929232a715f29e6cb7e3f0d0c790f41eb upstream.

dlm_posix_get fills out the relevant fields in the file_lock before
returning when there is a lock conflict, but doesn't clean out any of
the other fields in the file_lock.

When nfsd does a NFSv4 lockt call, it sets the fl_lmops to
nfsd_posix_mng_ops before calling the lower fs. When the lock comes back
after testing a lock on GFS2, it still has that field set. This confuses
nfsd into thinking that the file_lock is a nfsd4 lock.

Fix this by making DLM reinitialize the file_lock before copying the
fields from the conflicting lock.

Signed-off-by: Jeff Layton 
Signed-off-by: David Teigland 
Signed-off-by: Greg Kroah-Hartman

nfsd: only set file_lock.fl_lmops in nfsd4_lockt if a stateowner is found

2009-02-06T22:00:38+00:00

commit fa82a491275a613b15489aab4b99acecb00958d3 upstream.

nfsd4_lockt does a search for a lockstateowner when building the lock
struct to test. If one is found, it'll set fl_owner to it. Regardless of
whether that happens, it'll also set fl_lmops. Given that this lock is
basically a "lightweight" lock that's just used for checking conflicts,
setting fl_lmops is probably not appropriate for it.

This behavior exposed a bug in DLM's GETLK implementation where it
wasn't clearing out the fields in the file_lock before filling in
conflicting lock info. While we were able to fix this in DLM, it
still seems pointless and dangerous to set the fl_lmops this way
when we may have a NULL lockstateowner.

Signed-off-by: Jeff Layton 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

nfsd: Ensure nfsv4 calls the underlying filesystem on LOCKT

2009-02-06T22:00:37+00:00

commit 55ef1274dddd4de387c54d110e354ffbb6cdc706 upstream.

Since nfsv4 allows LOCKT without an open, but the ->lock() method is a
file method, we fake up a struct file in the nfsv4 code with just the
fields we need initialized.  But we forgot to initialize the file
operations, with the result that LOCKT never results in a call to the
filesystem's ->lock() method (if it exists).

We could just add that one more initialization.  But this hack of faking
up a struct file with only some fields initialized seems the kind of
thing that might cause more problems in the future.  We should either do
an open and get a real struct file, or make lock-testing an inode (not a
file) method.

This patch does the former.

Reported-by: Marc Eshel 
Tested-by: Marc Eshel 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

cifs: make sure we allocate enough storage for socket address

2009-02-06T22:00:34+00:00

commit a9ac49d303f967be0dabd97cb722c4a13109c6c2 upstream.

cifs_mount declares a struct sockaddr on the stack and then casts it
to the proper address type. The storage allocated is fine for ipv4,
but is too small for ipv6 addresses. Declare it as
"struct sockaddr_storage" instead of struct sockaddr".

This bug was manifesting itself as oopses and address corruption when
mounting IPv6 addresses.

Signed-off-by: Jeff Layton 
Tested-by: Stefan Bader 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

ext3: Add sanity check to make_indexed_dir

2009-02-02T16:28:13+00:00

commit a21102b55c4f8dfd3adb4a15a34cd62237b46039 upstream.

Make sure the rec_len field in the '..' entry is sane, lest we overrun
the directory block and cause a kernel oops on a purposefully
corrupted filesystem.

This fixes a bug related to a bug originally reported by Sami Liedes
for ext4 at:

http://bugzilla.kernel.org/show_bug.cgi?id=12430

Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

epoll: drop max_user_instances and rely only on max_user_watches

2009-02-02T16:28:13+00:00

commit 9df04e1f25effde823a600e755b51475d438f56b upstream.

Linus suggested to put limits where the money is, and max_user_watches
already does that w/out the need of max_user_instances.  That has the
advantage to mitigate the potential DoS while allowing pretty generous
default behavior.

Allowing top 4% of low memory (per user) to be allocated in epoll watches,
we have:

LOMEM    MAX_WATCHES (per user)
512MB    ~178000
1GB      ~356000
2GB      ~712000

A box with 512MB of lomem, will meet some challenge in hitting 180K
watches, socket buffers math teaches us.  No more max_user_instances
limits then.

Signed-off-by: Davide Libenzi 
Cc: Willy Tarreau 
Cc: Michael Kerrisk 
Cc: Bron Gondwana 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman