summaryrefslogtreecommitdiffstats
path: root/fs
AgeCommit message (Collapse)AuthorFilesLines
2013-11-09exportfs: stop retrying once we race with rename/removeJ. Bruce Fields1-5/+40
There are two places here where we could race with a rename or remove: - We could find the parent, but then be removed or renamed away from that parent directory before finding our name in that directory. - We could find the parent, and find our name in that parent, but then be renamed or removed before we look ourselves up by that name in that parent. In both cases the concurrent rename or remove will take care of reconnecting the directory that we're currently examining. Our target directory should then also be connected. Check this and clear DISCONNECTED in these cases instead of looping around again. Note: we *do* need to check that this actually happened if we want to be robust in the face of corrupted filesystems: a corrupted filesystem could just return a completely wrong parent, and we want to fail with an error in that case before starting to clear DISCONNECTED on non-DISCONNECTED filesystems. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09exportfs: clear DISCONNECTED on all parents soonerJ. Bruce Fields1-4/+21
Once we've found any connected parent, we know all our parents are connected--that's true even if there's a concurrent rename. May as well clear them all at once and be done with it. Reviewed-by: Cristoph Hellwig <hch@lst.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09exportfs: more detailed comment for path_reconnectJ. Bruce Fields1-1/+13
Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09exportfs: BUG_ON in crazy corner caseChristoph Hellwig1-6/+2
This would indicate a nasty bug in the dcache and has never triggered in the past 10 years as far as I know. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09dcache: fix outdated DCACHE_NEED_LOOKUP commentJ. Bruce Fields1-2/+2
The DCACHE_NEED_LOOKUP case referred to here was removed with 39e3c9553f34381a1b664c27b0c696a266a5735e "vfs: remove DCACHE_NEED_LOOKUP". There are only four real_lookup() callers and all of them pass in an unhashed dentry just returned from d_alloc. Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09dcache: don't clear DCACHE_DISCONNECTED too earlyJ. Bruce Fields1-1/+0
DCACHE_DISCONNECTED should not be cleared until we're sure the dentry is connected all the way up to the root of the filesystem. It *shouldn't* be cleared as soon as the dentry is connected to a parent. That will cause bugs at least on exportable filesystems. Acked-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09dcache: Don't set DISCONNECTED on "pseudo filesystem" dentriesJ. Bruce Fields1-4/+9
I can't for the life of me see any reason why anyone should care whether a dentry that is never hooked into the dentry cache would need DCACHE_DISCONNECTED set. This originates from 4b936885ab04dc6e0bb0ef35e0e23c1a7364d9e5 "fs: improve scalability of pseudo filesystems", which probably just made the false assumption the DCACHE_DISCONNECTED was meant to be set on anything not connected to a parent somehow. So this is just confusing. Ideally the only uses of DCACHE_DISCONNECTED would be in the filehandle-lookup code, which needs it to ensure dentries are connected into the dentry tree before use. I left d_alloc_pseudo there even though it's now equivalent to __d_alloc(), just on the theory the name is better documentation of its intended use outside dcache.c. Cc: Nick Piggin <npiggin@kernel.dk> Acked-by: Christoph Hellwig <hch@infradead.org> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09dcache: use IS_ROOT to decide where dentry is hashedJ. Bruce Fields1-1/+6
Every hashed dentry is either hashed in the dentry_hashtable, or a superblock's s_anon list. __d_drop() assumes it can determine which is the case by checking DCACHE_DISCONNECTED; this is not true. It is true that when DCACHE_DISCONNECTED is cleared, the dentry is not only hashed on dentry_hashtable, but is fully connected to its parents back to the root. But the converse is *not* true: fs/exportfs/expfs.c:reconnect_path() attempts to connect a directory (found by filehandle lookup) back to root by ascending to parents and performing lookups one at a time. It does not clear DCACHE_DISCONNECTED until it's done, and that is not at all an atomic process. In particular, it is possible for DCACHE_DISCONNECTED to be set on a dentry which is hashed on the dentry_hashtable. Instead, use IS_ROOT() to check which hash chain a dentry is on. This *does* work: Dentries are hashed only by: - d_obtain_alias, which adds an IS_ROOT() dentry to sb_anon. - __d_rehash, called by _d_rehash: hashes to the dentry's parent, and all callers of _d_rehash appear to have d_parent set to a "real" parent. - __d_rehash, called by __d_move: rehashes the moved dentry to hash chain determined by target, and assigns target's d_parent to its d_parent, before dropping the dentry's d_lock. Therefore I believe it's safe for a holder of a dentry's d_lock to assume that it is hashed on sb_anon if and only if IS_ROOT(dentry) is true. I believe the incorrect assumption about DCACHE_DISCONNECTED was originally introduced by ceb5bdc2d246 "fs: dcache per-bucket dcache hash locking". Also add a comment while we're here. Cc: Nick Piggin <npiggin@kernel.dk> Acked-by: Christoph Hellwig <hch@infradead.org> Reviewed-by: NeilBrown <neilb@suse.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09ocfs2: get rid of impossible checksAl Viro1-10/+0
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09qnx4: i_sb is never NULLAl Viro1-4/+0
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09exportfs: fix 32-bit nfsd handling of 64-bit inode numbersJ. Bruce Fields1-2/+16
Symptoms were spurious -ENOENTs on stat of an NFS filesystem from a 32-bit NFS server exporting a very large XFS filesystem, when the server's cache is cold (so the inodes in question are not in cache). Reviewed-by: Christoph Hellwig <hch@lst.de> Reported-by: Trevor Cordes <trevor@tecnopolis.ca> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09vfs: split out vfs_getattr_nosecJ. Bruce Fields1-6/+25
The filehandle lookup code wants this version of getattr. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09iget/iget5: don't bother with ->i_lock until we find a matchAl Viro2-15/+7
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09VFS: Put a small type field into struct dentry::d_flagsDavid Howells2-62/+75
Put a type field into struct dentry::d_flags to indicate if the dentry is one of the following types that relate particularly to pathwalk: Miss (negative dentry) Directory "Automount" directory (defective - no i_op->lookup()) Symlink Other (regular, socket, fifo, device) The type field is set to one of the first five types on a dentry by calls to __d_instantiate() and d_obtain_alias() from information in the inode (if one is given). The type is cleared by dentry_unlink_inode() when it reconstitutes an existing dentry as a negative dentry. Accessors provided are: d_set_type(dentry, type) d_is_directory(dentry) d_is_autodir(dentry) d_is_symlink(dentry) d_is_file(dentry) d_is_negative(dentry) d_is_positive(dentry) A bunch of checks in pathname resolution switched to those. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09elf{,_fdpic} coredump: get rid of pointless if (siginfo->si_signo)Al Viro2-37/+31
we can't get to do_coredump() if that condition isn't satisfied... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09constify do_coredump() argumentAl Viro2-3/+3
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09constify copy_siginfo_to_user{,32}()Al Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09... and kill anon_inode_getfile_private()Al Viro1-66/+0
it's a seriously misguided API, now fortunately without users. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09rework aio migrate pages to use aio fsBenjamin LaHaise1-6/+57
Don't abuse anon_inodes.c to host private files needed by aio; we can bloody well declare a mini-fs of our own instead of patching up what anon_inodes can create for us. Tested-by: Benjamin LaHaise <bcrl@kvack.org> Acked-by: Benjamin LaHaise <bcrl@kvack.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09take anon inode allocation to libfs.cAl Viro2-48/+45
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09new helper: dump_align()Al Viro3-16/+13
dump_skip to given alignment... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09dump_skip(): dump_seek() replacement taking coredump_paramsAl Viro4-40/+20
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09make dump_emit() use vfs_write() instead of banging at ->f_op->write directlyAl Viro1-5/+12
... and deal with short writes properly - the output might be to pipe, after all; as it is, e.g. no-MMU case of elf_fdpic coredump can write a whole lot more than a page worth of data at one call. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09binfmt_elf: count notes towards coredump limitAl Viro1-3/+0
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09aout: switch to dump_emitAl Viro1-4/+3
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09switch elf_coredump_extra_notes_write() to dump_emit()Al Viro1-4/+3
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09convert the rest of binfmt_elf_fdpic to dump_emit()Al Viro1-79/+31
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09binfmt_elf: convert writing actual dump pages to dump_emit()Al Viro1-11/+3
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09switch elf_core_write_extra_data() to dump_emit()Al Viro2-2/+6
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09switch elf_core_write_extra_phdrs() to dump_emit()Al Viro2-3/+5
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09new helper: dump_emit()Al Viro2-37/+37
dump_write() analog, takes core_dump_params instead of file, keeps track of the amount written in cprm->written and checks for cprm->limit. Start using it in binfmt_elf.c... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09coda_revalidate_inode(): switch to passing inode...Al Viro3-4/+3
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09fold __d_shrink() into its only remaining callerAl Viro1-22/+10
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09get rid of s_files and files_lockAl Viro4-143/+2
The only thing we need it for is alt-sysrq-r (emergency remount r/o) and these days we can do just as well without going through the list of files. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09get rid of {lock,unlock}_rcu_walk()Al Viro1-24/+14
those have become aliases for rcu_read_{lock,unlock}() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09RCU'd vfsmountsAl Viro4-82/+133
* RCU-delayed freeing of vfsmounts * vfsmount_lock replaced with a seqlock (mount_lock) * sequence number from mount_lock is stored in nameidata->m_seq and used when we exit RCU mode * new vfsmount flag - MNT_SYNC_UMOUNT. Set by umount_tree() when its caller knows that vfsmount will have no surviving references. * synchronize_rcu() done between unlocking namespace_sem in namespace_unlock() and doing pending mntput(). * new helper: legitimize_mnt(mnt, seq). Checks the mount_lock sequence number against seq, then grabs reference to mnt. Then it rechecks mount_lock again to close the race and either returns success or drops the reference it has acquired. The subtle point is that in case of MNT_SYNC_UMOUNT we can simply decrement the refcount and sod off - aforementioned synchronize_rcu() makes sure that final mntput() won't come until we leave RCU mode. We need that, since we don't want to end up with some lazy pathwalk racing with umount() and stealing the final mntput() from it - caller of umount() may expect it to return only once the fs is shut down and we don't want to break that. In other cases (i.e. with MNT_SYNC_UMOUNT absent) we have to do full-blown mntput() in case of mount_lock sequence number mismatch happening just as we'd grabbed the reference, but in those cases we won't be stealing the final mntput() from anything that would care. * mntput_no_expire() doesn't lock anything on the fast path now. Incidentally, SMP and UP cases are handled the same way - no ifdefs there. * normal pathname resolution does *not* do any writes to mount_lock. It does, of course, bump the refcounts of vfsmount and dentry in the very end, but that's it. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-11-09switch shrink_dcache_for_umount() to use of d_walk()Al Viro1-110/+85
we have too many iterators in fs/dcache.c... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-10-24fuse: rcu-delay freeing fuse_connAl Viro3-2/+4
makes ->permission() and ->d_revalidate() safety in RCU mode independent from vfsmount_lock. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-10-24ncpfs: rcu-delay unload_nls() and freeing ncp_serverAl Viro2-8/+13
makes ->d_hash() and ->d_compare() safety in RCU mode independent from vfsmount_lock. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-10-24fat: rcu-delay unloading nls and freeing sbiAl Viro2-8/+12
makes ->d_hash() and ->d_compare() safety in RCU mode independent from vfsmount_lock. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-10-24cifs: rcu-delay unload_nls() and freeing sbiAl Viro2-2/+9
makes ->d_hash(), ->d_compare() and ->permission() safety in RCU mode independent from vfsmount_lock. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-10-24autofs4: make freeing sbi rcu-delayedAl Viro2-9/+5
makes ->d_managed() safety in RCU mode independent from vfsmount_lock Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-10-24adfs: delayed freeing of sbiAl Viro2-5/+7
makes ->d_hash() and ->d_compare() safety in RCU mode independent from vfsmount_lock. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-10-24hpfs: make freeing sbi and codetables rcu-delayedAl Viro2-14/+15
makes ->d_hash() and ->d_compare() safety in RCU mode independent from vfsmount_lock Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-10-24make freeing super_block rcu-delayedAl Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-10-24vfs: introduce d_instantiate_no_diralias()Miklos Szeredi4-40/+32
...which just returns -EBUSY if a directory alias would be created. This is to be used by fuse mkdir to make sure that a buggy or malicious userspace filesystem doesn't do anything nasty. Previously fuse used a private mutex for this purpose, which can now go away. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
2013-10-24move taking vfsmount_lock down into prepend_path()Al Viro1-9/+2
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-10-24split __lookup_mnt() in two functionsAl Viro4-25/+30
Instead of passing the direction as argument (and checking it on every step through the hash chain), just have separate __lookup_mnt() and __lookup_mnt_last(). And use the standard iterators... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-10-24uninline destroy_super(), consolidate alloc_super()Al Viro1-120/+86
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-10-24isofs: don't pass dentry to isofs_hash{i,}_common()Al Viro1-6/+6
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-26 18:25:59 +0000