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

ocfs2: ocfs2_write_begin_nolock() should handle len=0

2009-09-09T03:34:12+00:00

commit 8379e7c46cc48f51197dd663fc6676f47f2a1e71 upstream.

Bug introduced by mainline commit e7432675f8ca868a4af365759a8d4c3779a3d922
The bug causes ocfs2_write_begin_nolock() to oops when len=0.

Signed-off-by: Sunil Mushran 
Signed-off-by: Joel Becker 
Signed-off-by: Greg Kroah-Hartman

xfs: fix spin_is_locked assert on uni-processor builds

2009-09-09T03:33:57+00:00

upstream commit a8914f3a6d72c97328597a556a99daaf5cc288ae

Without SMP or preemption spin_is_locked always returns false,
so we can't do an assert with it.  Instead use assert_spin_locked,
which does the right thing on all builds.


Signed-off-by: Christoph Hellwig 
Reviewed-by: Eric Sandeen 
Reported-by: Johannes Engel 
Tested-by: Johannes Engel 
Signed-off-by: Felix Blyakher 
Signed-off-by: Greg Kroah-Hartman

xfs: fix freeing of inodes not yet added to the inode cache

2009-09-09T03:33:56+00:00

upstream commit b36ec0428a06fcbdb67d61e9e664154e5dd9a8c7

When freeing an inode that lost race getting added to the inode cache we
must not call into ->destroy_inode, because that would delete the inode
that won the race from the inode cache radix tree.

This patch uses splits a new xfs_inode_free helper out of xfs_ireclaim
and uses that plus __destroy_inode to make sure we really only free
the memory allocted for the inode that lost the race, and not mess with
the inode cache state.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Eric Sandeen 
Reported-by: Alex Samad 
Reported-by: Andrew Randrianasulu 
Reported-by: Stephane 
Reported-by: Tommy 
Reported-by: Miah Gregory 
Reported-by: Gabriel Barazer 
Reported-by: Leandro Lucarella 
Reported-by: Daniel Burr 
Reported-by: Nickolay 
Reported-by: Michael Guntsche 
Reported-by: Dan Carley 
Reported-by: Michael Ole Olsen 
Reported-by: Michael Weissenbacher 
Reported-by: Martin Spott 
Reported-by: Christian Kujau 
Tested-by: Michael Guntsche 
Tested-by: Dan Carley 
Tested-by: Christian Kujau 
Signed-off-by: Greg Kroah-Hartman

vfs: add __destroy_inode

2009-09-09T03:33:56+00:00

backport of upstream commit 2e00c97e2c1d2ffc9e26252ca26b237678b0b772

When we want to tear down an inode that lost the add to the cache race
in XFS we must not call into ->destroy_inode because that would delete
the inode that won the race from the inode cache radix tree.

This patch provides the __destroy_inode helper needed to fix this,
the actual fix will be in th next patch.  As XFS was the only reason
destroy_inode was exported we shift the export to the new __destroy_inode.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Eric Sandeen 
Signed-off-by: Greg Kroah-Hartman

vfs: fix inode_init_always calling convention

2009-09-09T03:33:54+00:00

backport of upstream commit 54e346215e4fe2ca8c94c54e546cc61902060510

Currently inode_init_always calls into ->destroy_inode if the additional
initialization fails.  That's not only counter-intuitive because
inode_init_always did not allocate the inode structure, but in case of
XFS it's actively harmful as ->destroy_inode might delete the inode from
a radix-tree that has never been added.  This in turn might end up
deleting the inode for the same inum that has been instanciated by
another process and cause lots of cause subtile problems.

Also in the case of re-initializing a reclaimable inode in XFS it would
free an inode we still want to keep alive.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Eric Sandeen 
Signed-off-by: Greg Kroah-Hartman

ocfs2: Initialize the cluster we're writing to in a non-sparse extend

2009-09-09T03:33:52+00:00

commit e7432675f8ca868a4af365759a8d4c3779a3d922 upstream.

In a non-sparse extend, we correctly allocate (and zero) the clusters between
the old_i_size and pos, but we don't zero the portions of the cluster we're
writing to outside of pos<->len.

It handles clustersize > pagesize and blocksize < pagesize.

[Cleaned up by Joel Becker.]

Signed-off-by: Sunil Mushran 
Signed-off-by: Joel Becker 
Signed-off-by: Greg Kroah-Hartman

kernel_read: redefine offset type

2009-09-09T03:33:22+00:00

commit 6777d773a463ac045d333b989d4e44660f8d92ad upstream.

vfs_read() offset is defined as loff_t, but kernel_read()
offset is only defined as unsigned long. Redefine
kernel_read() offset as loff_t.

Signed-off-by: Mimi Zohar 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

mm: fix hugetlb bug due to user_shm_unlock call

2009-09-09T03:33:20+00:00

commit 353d5c30c666580347515da609dd74a2b8e9b828 upstream.

2.6.30's commit 8a0bdec194c21c8fdef840989d0d7b742bb5d4bc removed
user_shm_lock() calls in hugetlb_file_setup() but left the
user_shm_unlock call in shm_destroy().

In detail:
Assume that can_do_hugetlb_shm() returns true and hence user_shm_lock()
is not called in hugetlb_file_setup(). However, user_shm_unlock() is
called in any case in shm_destroy() and in the following
atomic_dec_and_lock(&up->__count) in free_uid() is executed and if
up->__count gets zero, also cleanup_user_struct() is scheduled.

Note that sched_destroy_user() is empty if CONFIG_USER_SCHED is not set.
However, the ref counter up->__count gets unexpectedly non-positive and
the corresponding structs are freed even though there are live
references to them, resulting in a kernel oops after a lots of
shmget(SHM_HUGETLB)/shmctl(IPC_RMID) cycles and CONFIG_USER_SCHED set.

Hugh changed Stefan's suggested patch: can_do_hugetlb_shm() at the
time of shm_destroy() may give a different answer from at the time
of hugetlb_file_setup().  And fixed newseg()'s no_id error path,
which has missed user_shm_unlock() ever since it came in 2.6.9.

Reported-by: Stefan Huber 
Signed-off-by: Hugh Dickins 
Tested-by: Stefan Huber 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Re-introduce page mapping check in mark_buffer_dirty()

2009-09-09T03:33:19+00:00

commit 8e9d78edea3ce5c0036f85b93091483f2f15443a upstream.

In commit a8e7d49aa7be728c4ae241a75a2a124cdcabc0c5 ("Fix race in
create_empty_buffers() vs __set_page_dirty_buffers()"), I removed a test
for a NULL page mapping unintentionally when some of the code inside
__set_page_dirty() was moved to the callers.

That removal generally didn't matter, since a filesystem would serialize
truncation (which clears the page mapping) against writing (which marks
the buffer dirty), so locking at a higher level (either per-page or an
inode at a time) should mean that the buffer page would be stable.  And
indeed, nothing bad seemed to happen.

Except it turns out that apparently reiserfs does something odd when
under load and writing out the journal, and we have a number of bugzilla
entries that look similar:

	http://bugzilla.kernel.org/show_bug.cgi?id=13556
	http://bugzilla.kernel.org/show_bug.cgi?id=13756
	http://bugzilla.kernel.org/show_bug.cgi?id=13876

and it looks like reiserfs depended on that check (the common theme
seems to be "data=journal", and a journal writeback during a truncate).

I suspect reiserfs should have some additional locking, but in the
meantime this should get us back to the pre-2.6.29 behavior.

Pattern-pointed-out-by: Roland Kletzing 
Cc: Jeff Mahoney 
Cc: Nick Piggin 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

poll/select: initialize triggered field of struct poll_wqueues

2009-09-09T03:33:13+00:00

commit b2add73dbf93fd50f00564d7abc3e2b9aa9dd20c upstream.

The triggered field of struct poll_wqueues introduced in commit
5f820f648c92a5ecc771a96b3c29aa6e90013bba ("poll: allow f_op->poll to
sleep").

It was first set to 1 in pollwake() (now __pollwake() ), tested and
later set to 0 in poll_schedule_timeout(), but not initialized before.

As a result when the process needs to sleep, triggered was likely to be
non-zero even if pollwake() is not called before the first
poll_schedule_timeout(), meaning schedule_hrtimeout_range() would not be
called and an extra loop calling all ->poll() would be done.

This patch initialize triggered to 0 in poll_initwait() so the ->poll()
are not called twice before the process goes to sleep when it needs to.

Signed-off-by: Guillaume Knispel 
Acked-by: Thomas Gleixner 
Acked-by: Tejun Heo 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman