Age | Commit message (Collapse) | Author | Files | Lines |
|
Ack-by: Boaz Harrosh <[email protected]>
Signed-off-by: Dmitry Monakhov <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Dmitry Monakhov <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Acked-by: Dave Kleikamp <[email protected]>
Signed-off-by: Dmitry Monakhov <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Dmitry Monakhov <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Dmitry Monakhov <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
This fixes sparse noise:
error: dubious one-bit signed bitfield
Signed-off-by: H Hartley Sweeten <[email protected]>
Cc: Alexander Viro <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
update the mnt of the path when it is not equal to the new one.
Signed-off-by: Huang Shijie <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
> =============================================
> [ 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 <[email protected]>
Cc: Tyler Hicks <[email protected]>
Cc: Dustin Kirkland <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
ADDPART_FLAG_RAID was introduced in commit d18d768, 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 <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
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: Christoph Hellwig <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
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 <[email protected]>
----
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: Al Viro <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Stephen Hemminger <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
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: Stephen Hemminger <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Al Viro <[email protected]>
|
|
... and switch the simple "loop over superblocks and do something"
loops to it.
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Al Viro <[email protected]>
|
|
... and get rid of the last __put_super_and_need_restart() caller
Signed-off-by: Al Viro <[email protected]>
|
|
If superblock had been still alive, we would've returned it...
Signed-off-by: Al Viro <[email protected]>
|
|
This one needs restarts...
Signed-off-by: Al Viro <[email protected]>
|
|
need list_for_each_entry_safe() here. Original didn't even
have restart logics, so if you race with umount() it blew up.
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Al Viro <[email protected]>
|
|
At the same time we can kill s_need_restart and local mutex in there.
__put_super() made public for a while; will be gone later.
Signed-off-by: Al Viro <[email protected]>
|
|
We used to remove from s_list and s_instances at the same
time. So let's *not* do the former and skip superblocks
that have empty s_instances in the loops over s_list.
The next step, of course, will be to get rid of rescan logics
in those loops.
Signed-off-by: Al Viro <[email protected]>
|
|
Make sure that s_umount is acquired *before* we drop the final
active reference; we still have the fast path (atomic_dec_unless)
and we have gotten rid of the window between the moment when
s_active hits zero and s_umount is acquired. Which simplifies
the living hell out of grab_super() and inotify pin_to_kill()
stuff.
Signed-off-by: Al Viro <[email protected]>
|
|
use atomic_inc_not_zero(&sb->s_active) instead of playing games with
checking ->s_count > S_BIAS
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Al Viro <[email protected]>
|
|
First of all, get_sb_nodev() grabs anon dev minor and we
never free it in ecryptfs ->kill_sb(). Moreover, on one
of the failure exits in ecryptfs_get_sb() we leak things -
it happens before we set ->s_root and ->put_super() won't
be called in that case. Solution: kill ->put_super(), do
all that stuff in ->kill_sb(). And use kill_anon_sb() instead
of generic_shutdown_super() to deal with anon dev leak.
Signed-off-by: Al Viro <[email protected]>
|
|
postpone simple_set_mnt() until we know we won't fail.
Signed-off-by: Al Viro <[email protected]>
|
|
Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
We set the "it's dead, don't mount on it" flag _and_ do not remove it if
we turn the damn thing negative and leave it around. And if it goes
positive afterwards, well...
Fortunately, there's only one place where that needs to be caught:
only d_delete() can turn the sucker negative without immediately freeing
it; all other places that can lead to ->d_iput() call are followed by
unconditionally freeing struct dentry in question. So the fix is obvious:
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16014
Reported-by: Adam Tkac <[email protected]>
Tested-by: Adam Tkac <[email protected]>
Cc: <[email protected]> [2.6.34.x]
Signed-off-by: Al Viro <[email protected]>
|
|
The auth_reply handler will (re)send any pending requests. For the
initial mon authenticate phase, that's correct, but when a auth ticket
renewal races with an in-flight request, we may resend a request message
that is already in flight. Avoid this by revoking the message before
sending it.
We should also avoid resending requests at all during ticket renewal; that
will come soon.
Signed-off-by: Sage Weil <[email protected]>
|
|
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: Tobias Klauser <[email protected]>
Signed-off-by: Sage Weil <[email protected]>
|
|
I made a V2 of this patch on top of my patches for VFS switches.
All the changes were due to change in some offsets.
rename - change name of file or directory
size[4] Trename tag[2] fid[4] newdirfid[4] name[s]
size[4] Rrename tag[2]
The rename message is used to change the name of a file, possibly moving it
to a new directory. The 9P wstat message can only rename a file within the
same directory.
Signed-off-by: Jim Garlick <[email protected]>
Signed-off-by: Sripathi Kodi <[email protected]>
Signed-off-by: Eric Van Hensbergen <[email protected]>
|
|
I made a V2 of this patch on top of my patches for VFS switches. The
change was adding v9fs_statfs pointer to v9fs_super_ops_dotl
instead of v9fs_super_ops.
statfs - get file system statistics
size[4] Tstatfs tag[2] fid[4]
size[4] Rstatfs tag[2] type[4] bsize[4] blocks[8] bfree[8] bavail[8]
files[8] ffree[8] fsid[8] namelen[4]
The statfs message is used to request file system information returned
by the statfs(2) system call, which is used by df(1) to report file
system and disk space usage.
Signed-off-by: Jim Garlick <[email protected]>
Signed-off-by: Sripathi Kodi <[email protected]>
Signed-off-by: Eric Van Hensbergen <[email protected]>
|
|
Implements VFS switches for 9p2000.L protocol.
Signed-off-by: Sripathi Kodi <[email protected]>
Signed-off-by: Eric Van Hensbergen <[email protected]>
|