- 21 May, 2010 40 commits
-
-
Dmitry Monakhov authored
Signed-off-by:
Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Dmitry Monakhov authored
Acked-by:
Joel Becker <joel.becker@oracle.com> Signed-off-by:
-
Dmitry Monakhov authored
Acked-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Signed-off-by:
-
Dmitry Monakhov authored
- also redesign minix_new_inode interface Signed-off-by:
-
Dmitry Monakhov authored
Signed-off-by:
-
Dmitry Monakhov authored
Acked-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Dmitry Monakhov authored
Acked-by:
-
Dmitry Monakhov authored
Ack-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
-
Dmitry Monakhov authored
Signed-off-by:
-
Dmitry Monakhov authored
Acked-by:
Dave Kleikamp <shaggy@linux.vnet.ibm.com> Signed-off-by:
-
Dmitry Monakhov authored
Signed-off-by:
-
Dmitry Monakhov authored
Signed-off-by:
-
H Hartley Sweeten authored
This fixes sparse noise: error: dubious one-bit signed bitfield Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Huang Shijie authored
update the mnt of the path when it is not equal to the new one. Signed-off-by:
Huang Shijie <shijie8@gmail.com> Signed-off-by:
-
Roland Dreier authored
> ============================================= > [ 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: [<ffffffff81139d31>] lock_rename+0x41/0xf0 > > but task is already holding lock: > (&s->s_vfs_rename_mutex){+.+.+.}, at: [<ffffffff81139d31>] 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: [<ffffffff81139d31>] lock_rename+0x41/0xf0 > #1: (&sb->s_type->i_mutex_key#11/1){+.+.+.}, at: [<ffffffff81139d5a>] lock_rename+0x6a/0xf0 > #2: (&sb->s_type->i_mutex_key#11/2){+.+.+.}, at: [<ffffffff81139d6f>] lock_rename+0x7f/0xf0 > > stack backtrace: > Pid: 4162, comm: firefox-3.5 Tainted: G C 2.6.31-2-generic #14~rbd3 > Call Trace: > [<ffffffff8108ae74>] print_deadlock_bug+0xf4/0x100 > [<ffffffff8108ce26>] validate_chain+0x4c6/0x750 > [<ffffffff8108d2e7>] __lock_acquire+0x237/0x430 > [<ffffffff8108d585>] lock_acquire+0xa5/0x150 > [<ffffffff81139d31>] ? lock_rename+0x41/0xf0 > [<ffffffff815526ad>] __mutex_lock_common+0x4d/0x3d0 > [<ffffffff81139d31>] ? lock_rename+0x41/0xf0 > [<ffffffff81139d31>] ? lock_rename+0x41/0xf0 > [<ffffffff8120eaf9>] ? ecryptfs_rename+0x99/0x170 > [<ffffffff81552b36>] mutex_lock_nested+0x46/0x60 > [<ffffffff81139d31>] lock_rename+0x41/0xf0 > [<ffffffff8120eb2a>] ecryptfs_rename+0xca/0x170 > [<ffffffff81139a9e>] vfs_rename_dir+0x13e/0x160 > [<ffffffff8113ac7e>] vfs_rename+0xee/0x290 > [<ffffffff8113c212>] ? __lookup_hash+0x102/0x160 > [<ffffffff8113d512>] sys_renameat+0x252/0x280 > [<ffffffff81133eb4>] ? cp_new_stat+0xe4/0x100 > [<ffffffff8101316a>] ? sysret_check+0x2e/0x69 > [<ffffffff8108c34d>] ? trace_hardirqs_on_caller+0x14d/0x190 > [<ffffffff8113d55b>] sys_rename+0x1b/0x20 > [<ffffffff81013132>] 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 <rdreier@cisco.com> Cc: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Cc: Dustin Kirkland <kirkland@canonical.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Cesar Eduardo Barros authored
ADDPART_FLAG_RAID was introduced in commit d18d7682, and most places were converted to use it instead of a hardcoded value. However, some places seem to have been missed. Change all of them to the symbolic names via the following semantic patch: @@ struct parsed_partitions *state; expression E; @@ ( - state->parts[E].flags = 1 + state->parts[E].flags = ADDPART_FLAG_RAID | - state->parts[E].flags |= 1 + state->parts[E].flags |= ADDPART_FLAG_RAID | - state->parts[E].flags = 2 + state->parts[E].flags = ADDPART_FLAG_WHOLEDISK | - state->parts[E].flags |= 2 + state->parts[E].flags |= ADDPART_FLAG_WHOLEDISK ) Signed-off-by:
Cesar Eduardo Barros <cesarb@cesarb.net> Signed-off-by:
-
Christoph Hellwig authored
Now that the last user passing a NULL file pointer is gone we can remove the redundant dentry argument and associated hacks inside vfs_fsynmc_range. The next step will be removig the dentry argument from ->fsync, but given the luck with the last round of method prototype changes I'd rather defer this until after the main merge window. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Christoph Hellwig authored
Instead of just looking up a path use do_filp_open to get us a file structure for the nfs4 recovery directory. This allows us to get rid of the last non-standard vfs_fsync caller with a NULL file pointer. [AV: should be using fput(), not filp_close()] Signed-off-by:
-
Richard Kennedy authored
Using atomic_inc_return in __iget(struct inode *inode) makes the intent of this code clearer and generates less code on processors that have this operation. On x86_64 this patch reduces the text size of inode.o by 12 bytes. Signed-off-by:
Richard Kennedy <richard@rsk.demon.co.uk> ---- patch against 2.6.34-rc7 compiled & tested on x86_64 AMD X2 I've been running with this patch applied for several weeks with no obvious problems. regards Richard Signed-off-by:
-
Eric Paris authored
anon_inode_mkinode() sets inode->i_mode = S_IRUSR | S_IWUSR; This means that (inode->i_mode & S_IFMT) == 0. This trips up some SELinux code that needs to determine if a given inode is a regular file, a directory, etc. The easiest solution is to just make sure that the anon_inode also sets S_IFREG. Signed-off-by:
Eric Paris <eparis@redhat.com> Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
Signed-off-by:
-
Stephen Hemminger authored
The entries in xattr handler table should be immutable (ie const) like other operation tables. Later patches convert common filesystems. Uncoverted filesystems will still work, but will generate a compiler warning. Signed-off-by:
-
Josef Bacik authored
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 <josef@redhat.com> Signed-off-by:
-
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
... kill their private list, while we are at it Signed-off-by: -
Al Viro authored
... and switch the simple "loop over superblocks and do something" loops to it. Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
... and get rid of the last __put_super_and_need_restart() caller Signed-off-by: -
Al Viro authored
If superblock had been still alive, we would've returned it... Signed-off-by: -
Al Viro authored
This one needs restarts... Signed-off-by:
-
