linux.git/fs/super.c, branch v2.6.35

fs: fix superblock iteration race

2010-06-29T17:38:22+00:00

list_for_each_entry_safe is not suitable to protect against concurrent
modification of the list. 6754af6 introduced a race in sb walking.

list_for_each_entry can use the trick of pinning the current entry in
the list before we drop and retake the lock because it subsequently
follows cur->next. However list_for_each_entry_safe saves n=cur->next
for following before entering the loop body, so when the lock is
dropped, n may be deleted.

Signed-off-by: Nick Piggin 
Cc: Christoph Hellwig 
Cc: John Stultz 
Cc: Frank Mayhar 
Cc: Al Viro 
Signed-off-by: Linus Torvalds

Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs-2.6

2010-05-30T16:11:11+00:00

* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs-2.6:
  quota: Convert quota statistics to generic percpu_counter
  ext3 uses rb_node = NULL; to zero rb_root.
  quota: Fixup dquot_transfer
  reiserfs: Fix resuming of quotas on remount read-write
  pohmelfs: Remove dead quota code
  ufs: Remove dead quota code
  udf: Remove dead quota code
  quota: rename default quotactl methods to dquot_
  quota: explicitly set ->dq_op and ->s_qcop
  quota: drop remount argument to ->quota_on and ->quota_off
  quota: move unmount handling into the filesystem
  quota: kill the vfs_dq_off and vfs_dq_quota_on_remount wrappers
  quota: move remount handling into the filesystem
  ocfs2: Fix use after free on remount read-only

Fix up conflicts in fs/ext4/super.c and fs/ufs/file.c

fs/super: fix kernel-doc warning

2010-05-28T02:06:23+00:00

Fix fs/super.c kernel-doc warning and function notation:
Warning(fs/super.c:957): No description found for parameter 'sb'

Signed-off-by: Randy Dunlap 
Cc: Alexander Viro 
Signed-off-by: Al Viro

quota: explicitly set ->dq_op and ->s_qcop

2010-05-24T12:10:17+00:00

Only set the quota operation vectors if the filesystem actually supports
quota instead of doing it for all filesystems in alloc_super().

[Jan Kara: Export dquot_operations and vfs_quotactl_ops]

Signed-off-by: Christoph Hellwig 
Signed-off-by: Jan Kara

quota: move unmount handling into the filesystem

2010-05-24T12:09:12+00:00

Currently the VFS calls into the quotactl interface for unmounting
filesystems.  This means filesystems with their own quota handling
can't easily distinguish between user-space originating quotaoff
and an unount.  Instead move the responsibily of the unmount handling
into the filesystem to be consistent with all other dquot handling.

Note that we do call dquot_disable a lot later now, e.g. after
a sync_filesystem.  But this is fine as the quota code does all its
writes via blockdev's mapping and that is synced even later.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Jan Kara

quota: move remount handling into the filesystem

2010-05-24T12:06:39+00:00

Currently do_remount_sb calls into the dquot code to tell it about going
from rw to ro and ro to rw.  Move this code into the filesystem to
not depend on the dquot code in the VFS - note ocfs2 already ignores
these calls and handles remount by itself.  This gets rid of overloading
the quotactl calls and allows to unify the VFS and XFS codepaths in
that area later.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Jan Kara

vfs: add lockdep annotation to s_vfs_rename_key for ecryptfs

2010-05-21T22:31:22+00:00

 >  =============================================
 >  [ INFO: possible recursive locking detected ]
 >  2.6.31-2-generic #14~rbd3
 >  ---------------------------------------------
 >  firefox-3.5/4162 is trying to acquire lock:
 >   (&s->s_vfs_rename_mutex){+.+.+.}, at: [] lock_rename+0x41/0xf0
 >
 >  but task is already holding lock:
 >   (&s->s_vfs_rename_mutex){+.+.+.}, at: [] lock_rename+0x41/0xf0
 >
 >  other info that might help us debug this:
 >  3 locks held by firefox-3.5/4162:
 >   #0:  (&s->s_vfs_rename_mutex){+.+.+.}, at: [] lock_rename+0x41/0xf0
 >   #1:  (&sb->s_type->i_mutex_key#11/1){+.+.+.}, at: [] lock_rename+0x6a/0xf0
 >   #2:  (&sb->s_type->i_mutex_key#11/2){+.+.+.}, at: [] lock_rename+0x7f/0xf0
 >
 >  stack backtrace:
 >  Pid: 4162, comm: firefox-3.5 Tainted: G         C 2.6.31-2-generic #14~rbd3
 >  Call Trace:
 >   [] print_deadlock_bug+0xf4/0x100
 >   [] validate_chain+0x4c6/0x750
 >   [] __lock_acquire+0x237/0x430
 >   [] lock_acquire+0xa5/0x150
 >   [] ? lock_rename+0x41/0xf0
 >   [] __mutex_lock_common+0x4d/0x3d0
 >   [] ? lock_rename+0x41/0xf0
 >   [] ? lock_rename+0x41/0xf0
 >   [] ? ecryptfs_rename+0x99/0x170
 >   [] mutex_lock_nested+0x46/0x60
 >   [] lock_rename+0x41/0xf0
 >   [] ecryptfs_rename+0xca/0x170
 >   [] vfs_rename_dir+0x13e/0x160
 >   [] vfs_rename+0xee/0x290
 >   [] ? __lookup_hash+0x102/0x160
 >   [] sys_renameat+0x252/0x280
 >   [] ? cp_new_stat+0xe4/0x100
 >   [] ? sysret_check+0x2e/0x69
 >   [] ? trace_hardirqs_on_caller+0x14d/0x190
 >   [] sys_rename+0x1b/0x20
 >   [] system_call_fastpath+0x16/0x1b

The trace above is totally reproducible by doing a cross-directory
rename on an ecryptfs directory.

The issue seems to be that sys_renameat() does lock_rename() then calls
into the filesystem; if the filesystem is ecryptfs, then
ecryptfs_rename() again does lock_rename() on the lower filesystem, and
lockdep can't tell that the two s_vfs_rename_mutexes are different.  It
seems an annotation like the following is sufficient to fix this (it
does get rid of the lockdep trace in my simple tests); however I would
like to make sure I'm not misunderstanding the locking, hence the CC
list...

Signed-off-by: Roland Dreier 
Cc: Tyler Hicks 
Cc: Dustin Kirkland 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro

Introduce freeze_super and thaw_super for the fsfreeze ioctl

2010-05-21T22:31:18+00:00

Currently the way we do freezing is by passing sb>s_bdev to freeze_bdev and then
letting it do all the work.  But freezing is more of an fs thing, and doesn't
really have much to do with the bdev at all, all the work gets done with the
super.  In btrfs we do not populate s_bdev, since we can have multiple bdev's
for one fs and setting s_bdev makes removing devices from a pool kind of tricky.
This means that freezing a btrfs filesystem fails, which causes us to corrupt
with things like tux-on-ice which use the fsfreeze mechanism.  So instead of
populating sb->s_bdev with a random bdev in our pool, I've broken the actual fs
freezing stuff into freeze_super and thaw_super.  These just take the
super_block that we're freezing and does the appropriate work.  It's basically
just copy and pasted from freeze_bdev.  I've then converted freeze_bdev over to
use the new super helpers.  I've tested this with ext4 and btrfs and verified
everything continues to work the same as before.

The only new gotcha is multiple calls to the fsfreeze ioctl will return EBUSY if
the fs is already frozen.  I thought this was a better solution than adding a
freeze counter to the super_block, but if everybody hates this idea I'm open to
suggestions.  Thanks,

Signed-off-by: Josef Bacik 
Signed-off-by: Al Viro

Trim includes in fs/super.c

2010-05-21T22:31:17+00:00

Signed-off-by: Al Viro

Move grabbing s_umount to callers of grab_super()

2010-05-21T22:31:17+00:00

Signed-off-by: Al Viro