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

ecryptfs: initialize private persistent file before dereferencing pointer

2010-01-25T18:49:18+00:00

commit e27759d7a333d1f25d628c4f7caf845c51be51c2 upstream.

Ecryptfs_open dereferences a pointer to the private lower file (the one
stored in the ecryptfs inode), without checking if the pointer is NULL.
Right afterward, it initializes that pointer if it is NULL.  Swap order of
statements to first initialize.  Bug discovered by Duckjin Kang.

Signed-off-by: Duckjin Kang 
Signed-off-by: Erez Zadok 
Cc: Dustin Kirkland 
Cc: Al Viro 
Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman

ecryptfs: use after free

2010-01-25T18:49:17+00:00

commit ece550f51ba175c14ec3ec047815927d7386ea1f upstream.

The "full_alg_name" variable is used on a couple error paths, so we
shouldn't free it until the end.

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

reiserfs: truncate blocks not used by a write

2010-01-22T23:18:23+00:00

commit ec8e2f7466ca370f5e09000ca40a71759afc9ac8 upstream.

It can happen that write does not use all the blocks allocated in
write_begin either because of some filesystem error (like ENOSPC) or
because page with data to write has been removed from memory.  We truncate
these blocks so that we don't have dangling blocks beyond i_size.

Cc: Jeff Mahoney 
Signed-off-by: Jan Kara 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

inotify: only warn once for inotify problems

2010-01-22T23:17:56+00:00

commit 976ae32be45a736acd49215a7e4771ff91f161c3 upstream.

inotify will WARN() if it finds that the idr and the fsnotify internals
somehow got out of sync.  It was only supposed to do this once but due
to this stupid bug it would warn every single time a problem was
detected.

Signed-off-by: Eric Paris 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

inotify: do not reuse watch descriptors

2010-01-22T23:17:55+00:00

commit 9e572cc9877ee6c43af60778f6b8d5ba0692d935 upstream.

Since commit 7e790dd5fc937bc8d2400c30a05e32a9e9eef276 ("inotify: fix
error paths in inotify_update_watch") inotify changed the manor in which
it gave watch descriptors back to userspace.  Previous to this commit
inotify acted like the following:

  inotify_add_watch(X, Y, Z) = 1
  inotify_rm_watch(X, 1);
  inotify_add_watch(X, Y, Z) = 2

but after this patch inotify would return watch descriptors like so:

  inotify_add_watch(X, Y, Z) = 1
  inotify_rm_watch(X, 1);
  inotify_add_watch(X, Y, Z) = 1

which I saw as equivalent to opening an fd where

  open(file) = 1;
  close(1);
  open(file) = 1;

seemed perfectly reasonable.  The issue is that quite a bit of userspace
apparently relies on the behavior in which watch descriptors will not be
quickly reused.  KDE relies on it, I know some selinux packages rely on
it, and I have heard complaints from other random sources such as debian
bug 558981.

Although the man page implies what we do is ok, we broke userspace so
this patch almost reverts us to the old behavior.  It is still slightly
racey and I have patches that would fix that, but they are rather large
and this will fix it for all real world cases.  The race is as follows:

 - task1 creates a watch and blocks in idr_new_watch() before it updates
   the hint.
 - task2 creates a watch and updates the hint.
 - task1 updates the hint with it's older wd
 - task removes the watch created by task2
 - task adds a new watch and will reuse the wd originally given to task2

it requires moving some locking around the hint (last_wd) but this should
solve it for the real world and be -stable safe.

As a side effect this patch papers over a bug in the lib/idr code which
is causing a large number WARN's to pop on people's system and many
reports in kerneloops.org.  I'm working on the root cause of that idr
bug seperately but this should make inotify immune to that issue.

Signed-off-by: Eric Paris 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

quota: Fix dquot_transfer for filesystems different from ext4

2010-01-18T18:19:43+00:00

commit 05b5d898235401c489c68e1f3bc5706a29ad5713 upstream.

Commit fd8fbfc1 modified the way we find amount of reserved space
belonging to an inode. The amount of reserved space is checked
from dquot_transfer and thus inode_reserved_space gets called
even for filesystems that don't provide get_reserved_space callback
which results in a BUG.

Fix the problem by checking get_reserved_space callback and return 0 if
the filesystem does not provide it.

CC: Dmitry Monakhov 
Signed-off-by: Jan Kara 
Signed-off-by: Greg Kroah-Hartman

nfsd: make sure data is on disk before calling ->fsync

2010-01-18T18:19:18+00:00

commit 7211a4e859ad070b28545c06e0a6cb60b3b8aa31 upstream.

nfsd is not using vfs_fsync, so I missed it when changing the calling
convention during the 2.6.32 window.  This patch fixes it to not only
start the data writeout, but also wait for it to complete before calling
into ->fsync.

Signed-off-by: Christoph Hellwig 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

exofs: simple_write_end does not mark_inode_dirty

2010-01-18T18:19:15+00:00

commit efd124b999fb4d426b30675f1684521af0872789 upstream.

exofs uses simple_write_end() for it's .write_end handler. But
it is not enough because simple_write_end() does not call
mark_inode_dirty() when it extends i_size. So even if we do
call mark_inode_dirty at beginning of write out, with a very
long IO and a saturated system we might get the .write_inode()
called while still extend-writing to file and miss out on the last
i_size updates.

So override .write_end, call simple_write_end(), and afterwords if
i_size was changed call mark_inode_dirty().

It stands to logic that since simple_write_end() was the one extending
i_size it should also call mark_inode_dirty(). But it looks like all
users of simple_write_end() are memory-bound pseudo filesystems, who
could careless about mark_inode_dirty(). I might submit a
warning-comment patch to simple_write_end() in future.

Signed-off-by: Boaz Harrosh 
Signed-off-by: Greg Kroah-Hartman

fasync: split 'fasync_helper()' into separate add/remove functions

2010-01-18T18:19:11+00:00

commit 53281b6d34d44308372d16acb7fb5327609f68b6 upstream.

Yes, the add and remove cases do share the same basic loop and the
locking, but the compiler can inline and then CSE some of the end result
anyway.  And splitting it up makes the code way easier to follow,
and makes it clearer exactly what the semantics are.

In particular, we must make sure that the FASYNC flag in file->f_flags
exactly matches the state of "is this file on any fasync list", since
not only is that flag visible to user space (F_GETFL), but we also use
that flag to check whether we need to remove any fasync entries on file
close.

We got that wrong for the case of a mixed use of file locking (which
tries to remove any fasync entries for file leases) and fasync.

Splitting the function up also makes it possible to do some future
optimizations without making the function even messier.  In particular,
since the FASYNC flag has to match the state of "is this on a list", we
can do the following future optimizations:

 - on remove, we don't even need to get the locks and traverse the list
   if FASYNC isn't set, since we can know a priori that there is no
   point (this is effectively the same optimization that we already do
   in __fput() wrt removing fasync on file close)

 - on add, we can use the FASYNC flag to decide whether we are changing
   an existing entry or need to allocate a new one.

but this is just the cleanup + fix for the FASYNC flag.

Acked-by: Al Viro 
Tested-by: Tavis Ormandy 
Cc: Jeff Dike 
Cc: Matt Mackall 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

generic_permission: MAY_OPEN is not write access

2010-01-06T23:05:26+00:00

commit 7ea6600148c265b1fd53e521022b1d7aec81d974 upstream.

generic_permission was refusing CAP_DAC_READ_SEARCH-enabled
processes from opening DAC-protected files read-only, because
do_filp_open adds MAY_OPEN to the open mask.

Ignore MAY_OPEN.  After this patch, CAP_DAC_READ_SEARCH is
again sufficient to open(fname, O_RDONLY) on a file to which
DAC otherwise refuses us read permission.

Reported-by: Mike Kazantsev 
Signed-off-by: Serge E. Hallyn 
Tested-by: Mike Kazantsev 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman