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

fs: sys_sync fix

2009-01-25T00:41:52+00:00

commit 856bf4d717feb8c55d4e2f817b71ebb70cfbc67b upstream.

s_syncing livelock avoidance was breaking data integrity guarantee of
sys_sync, by allowing sys_sync to skip writing or waiting for superblocks
if there is a concurrent sys_sync happening.

This livelock avoidance is much less important now that we don't have the
get_super_to_sync() call after every sb that we sync.  This was replaced
by __put_super_and_need_restart.

Signed-off-by: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

fs: sync_sb_inodes fix

2009-01-25T00:41:52+00:00

commit 38f21977663126fef53f5585e7f1653d8ebe55c4 upstream.

Fix data integrity semantics required by sys_sync, by iterating over all
inodes and waiting for any writeback pages after the initial writeout.
Comments explain the exact problem.

Signed-off-by: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

fs: remove WB_SYNC_HOLD

2009-01-25T00:41:51+00:00

commit 4f5a99d64c17470a784a6c68064207d82e3e74a5 upstream.

Remove WB_SYNC_HOLD.  The primary motiviation is the design of my
anti-starvation code for fsync.  It requires taking an inode lock over the
sync operation, so we could run into lock ordering problems with multiple
inodes.  It is possible to take a single global lock to solve the ordering
problem, but then that would prevent a future nice implementation of "sync
multiple inodes" based on lock order via inode address.

Seems like a backward step to remove this, but actually it is busted
anyway: we can't use the inode lists for data integrity wait: an inode can
be taken off the dirty lists but still be under writeback.  In order to
satisfy data integrity semantics, we should wait for it to finish
writeback, but if we only search the dirty lists, we'll miss it.

It would be possible to have a "writeback" list, for sys_sync, I suppose.
But why complicate things by prematurely optimise?  For unmounting, we
could avoid the "livelock avoidance" code, which would be easier, but
again premature IMO.

Fixing the existing data integrity problem will come next.

Signed-off-by: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm: do_sync_mapping_range integrity fix

2009-01-25T00:41:48+00:00

commit ee53a891f47444c53318b98dac947ede963db400 upstream.

Chris Mason notices do_sync_mapping_range didn't actually ask for data
integrity writeout.  Unfortunately, it is advertised as being usable for
data integrity operations.

This is a data integrity bug.

Signed-off-by: Nick Piggin 
Cc: Chris Mason 
Cc: Dave Chinner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

XFS: truncate readdir offsets to signed 32 bit values

2009-01-18T18:44:06+00:00

commit 15440319767942a363f282d6585303d3d75088ba upstream.

John Stanley reported EOVERFLOW errors in readdir from his self-build
glibc.  I traced this down to glibc enabling d_off overflow checks
in one of the about five million different getdents implementations.

In 2.6.28 Dave Woodhouse moved our readdir double buffering required
for NFS4 readdirplus into nfsd and at that point we lost the capping
of the directory offsets to 32 bit signed values.  Johns glibc used
getdents64 to even implement readdir for normal 32 bit offset dirents,
and failed with EOVERFLOW only if this happens on the first dirent in
a getdents call.  I managed to come up with a testcase that uses
raw getdents and does the EOVERFLOW check manually.  We always hit
it with our last entry due to the special end of directory marker.

The patch below is a dumb version of just putting back the masking,
to make sure we have the same behavior as in 2.6.27 and earlier.

I will work on a better and cleaner fix for 2.6.30.

Reported-by: John Stanley 
Tested-by: John Stanley 
Signed-off-by: Christoph Hellwig 
Reviewed-by: Dave Chinner 
Signed-off-by: Lachlan McIlroy 
Signed-off-by: Greg Kroah-Hartman

eCryptfs: check readlink result was not an error before using it

2009-01-18T18:44:04+00:00

commit a17d5232de7b53d34229de79ec22f4bb04adb7e4 upstream.

The result from readlink is being used to index into the link name
buffer without checking whether it is a valid length. If readlink
returns an error this will fault or cause memory corruption.

Cc: Tyler Hicks 
Cc: Dustin Kirkland 
Cc: ecryptfs-devel@lists.launchpad.net
Signed-off-by: Duane Griffin 
Acked-by: Michael Halcrow 
Acked-by: Tyler Hicks 
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

nfs: remove redundant tests on reading new pages

2009-01-18T18:44:03+00:00

commit 136221fc3219b3805c48db5da065e8e3467175d4 upstream.

aops->readpages() and its NFS helper readpage_async_filler() will only
be called to do readahead I/O for newly allocated pages. So it's not
necessary to test for the always 0 dirty/uptodate page flags.

The removal of nfs_wb_page() call also fixes a readahead bug: the NFS
readahead has been synchronous since 2.6.23, because that call will
clear PG_readahead, which is the reminder for asynchronous readahead.

More background: the PG_readahead page flag is shared with PG_reclaim,
one for read path and the other for write path. clear_page_dirty_for_io()
unconditionally clears PG_readahead to prevent possible readahead residuals,
assuming itself to be always called in the write path. However, NFS is one
and the only exception in that it _always_ calls clear_page_dirty_for_io()
in the read path, i.e. for readpages()/readpage().

Cc: Trond Myklebust 
Signed-off-by: Wu Fengguang 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

fix switch_names() breakage in short-to-short case

2009-01-18T18:44:03+00:00

commit dc711ca35f9d95a1eec02118e0c298b5e3068315 upstream.

We want ->name.len to match the resulting name on *both*
source and target

Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

Fix timeouts in sys_pselect7

2009-01-18T18:44:02+00:00

commit 62568510b8e2679cbc331d7de10ea9ba81ae8b3d upstream.

Since we (Analog Devices) updated our Blackfin kernel to 2.6.28, we've
seen occasional 5-second hangs from telnet.  telnetd calls select with a
NULL timeout, but with the new kernel, the system call occasionally
returns 0, which causes telnet to call sleep (5).  This did not happen
with earlier kernels.

The code in sys_pselect7 looks a bit strange, in particular the variable
"to" is initialized to NULL, then changed if a non-null timeout was
passed in, but not used further.  It needs to be passed to
core_sys_select instead of &end_time.

This bug was introduced by 8ff3e8e85fa6c312051134b3953e397feb639f51
("select: switch select() and poll() over to hrtimers").

Signed-off-by: Bernd Schmidt 
Reviewed-by: Ulrich Drepper 
Tested-by: Robin Getz 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

System call wrappers part 33

2009-01-18T18:44:01+00:00

commit 2b66421995d2e93c9d1a0111acf2581f8529c6e5 upstream.

Signed-off-by: Heiko Carstens 
Signed-off-by: Greg Kroah-Hartman