aboutsummaryrefslogtreecommitdiffstats
path: root/net (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2018-05-22ncp_lookup(): use d_splice_alias()Al Viro1-27/+15
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22hfsplus: switch to d_splice_alias()Al Viro1-2/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22hfs: don't allow mounting over .../rsrcAl Viro1-0/+1
That's one case when unlink() destroys a subtree, thanks to "resource fork" idiocy. We might forcibly evict that shit on unlink(2), but for now let's just disallow overmounting; as it is, anything that plays games with those would leak mounts. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22hfs: use d_splice_alias()Al Viro2-15/+8
code is simpler that way Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22omfs_lookup(): report IO errors, use d_splice_alias()Al Viro1-4/+3
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22orangefs_lookup: simplifyAl Viro1-56/+8
d_splice_alias() can handle NULL and ERR_PTR() for inode just fine... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22openpromfs: switch to d_splice_alias()Al Viro1-2/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22xfs_vn_lookup: simplify a bitAl Viro1-8/+8
have all post-xfs_lookup() branches converge on d_splice_alias() Cc: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22adfs_lookup: do not fail with ENOENT on negatives, use d_splice_alias()Al Viro1-5/+5
Cc: Russell King <linux@armlinux.org.uk> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22adfs_lookup_byname: .. *is* taken care of in fs/namei.cAl Viro1-14/+0
Cc: Russell King <linux@armlinux.org.uk> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22romfs_lookup: switch to d_splice_alias()Al Viro1-27/+9
... and hash negative lookups Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22qnx6_lookup: switch to d_splice_alias()Al Viro1-6/+2
... and hash negative lookups Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22ubifs_lookup: use d_splice_alias()Al Viro1-28/+15
code is simpler that way Acked-by: Richard Weinberger <richard@nod.at> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22sysv_lookup: use d_splice_alias()Al Viro1-7/+2
code is simpler that way Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22qnx4_lookup: use d_splice_alias()Al Viro1-6/+2
code is simpler that way Acked-by: Anders Larsen <al@alarsen.net> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22minix_lookup: use d_splice_alias()Al Viro1-6/+2
code is simpler that way Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22freevxfs_lookup(): use d_splice_alias()Al Viro1-6/+2
code is simpler that way Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22cramfs_lookup(): use d_splice_alias()Al Viro1-4/+1
simpler code that way, actually Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22bfs_add_entry: pass name/len as qstr pointerAl Viro1-11/+7
same story as with bfs_find_entry() Cc: "Tigran A. Aivazian" <aivazian.tigran@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22bfs_find_entry: pass name/len as qstr pointerAl Viro1-10/+8
all callers feed something->name/something->len anyway Cc: "Tigran A. Aivazian" <aivazian.tigran@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-22bfs_lookup(): use d_splice_alias()Al Viro1-6/+1
code is actually simpler that way. Acked-by: "Tigran A. Aivazian" <aivazian.tigran@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-21aio: fix io_destroy(2) vs. lookup_ioctx() raceAl Viro1-2/+2
kill_ioctx() used to have an explicit RCU delay between removing the reference from ->ioctx_table and percpu_ref_kill() dropping the refcount. At some point that delay had been removed, on the theory that percpu_ref_kill() itself contained an RCU delay. Unfortunately, that was the wrong kind of RCU delay and it didn't care about rcu_read_lock() used by lookup_ioctx(). As the result, we could get ctx freed right under lookup_ioctx(). Tejun has fixed that in a6d7cff472e ("fs/aio: Add explicit RCU grace period when freeing kioctx"); however, that fix is not enough. Suppose io_destroy() from one thread races with e.g. io_setup() from another; CPU1 removes the reference from current->mm->ioctx_table[...] just as CPU2 has picked it (under rcu_read_lock()). Then CPU1 proceeds to drop the refcount, getting it to 0 and triggering a call of free_ioctx_users(), which proceeds to drop the secondary refcount and once that reaches zero calls free_ioctx_reqs(). That does INIT_RCU_WORK(&ctx->free_rwork, free_ioctx); queue_rcu_work(system_wq, &ctx->free_rwork); and schedules freeing the whole thing after RCU delay. In the meanwhile CPU2 has gotten around to percpu_ref_get(), bumping the refcount from 0 to 1 and returned the reference to io_setup(). Tejun's fix (that queue_rcu_work() in there) guarantees that ctx won't get freed until after percpu_ref_get(). Sure, we'd increment the counter before ctx can be freed. Now we are out of rcu_read_lock() and there's nothing to stop freeing of the whole thing. Unfortunately, CPU2 assumes that since it has grabbed the reference, ctx is *NOT* going away until it gets around to dropping that reference. The fix is obvious - use percpu_ref_tryget_live() and treat failure as miss. It's not costlier than what we currently do in normal case, it's safe to call since freeing *is* delayed and it closes the race window - either lookup_ioctx() comes before percpu_ref_kill() (in which case ctx->users won't reach 0 until the caller of lookup_ioctx() drops it) or lookup_ioctx() fails, ctx->users is unaffected and caller of lookup_ioctx() doesn't see the object in question at all. Cc: stable@kernel.org Fixes: a6d7cff472e "fs/aio: Add explicit RCU grace period when freeing kioctx" Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-21ext2: fix a block leakAl Viro1-10/+0
open file, unlink it, then use ioctl(2) to make it immutable or append only. Now close it and watch the blocks *not* freed... Immutable/append-only checks belong in ->setattr(). Note: the bug is old and backport to anything prior to 737f2e93b972 ("ext2: convert to use the new truncate convention") will need these checks lifted into ext2_setattr(). Cc: stable@kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-21nfsd: vfs_mkdir() might succeed leaving dentry negative unhashedAl Viro1-0/+22
That can (and does, on some filesystems) happen - ->mkdir() (and thus vfs_mkdir()) can legitimately leave its argument negative and just unhash it, counting upon the lookup to pick the object we'd created next time we try to look at that name. Some vfs_mkdir() callers forget about that possibility... Acked-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-21cachefiles: vfs_mkdir() might succeed leaving dentry negative unhashedAl Viro1-0/+10
That can (and does, on some filesystems) happen - ->mkdir() (and thus vfs_mkdir()) can legitimately leave its argument negative and just unhash it, counting upon the lookup to pick the object we'd created next time we try to look at that name. Some vfs_mkdir() callers forget about that possibility... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-21unfuck sysfs_mount()Al Viro1-3/+3
new_sb is left uninitialized in case of early failures in kernfs_mount_ns(), and while IS_ERR(root) is true in all such cases, using IS_ERR(root) || !new_sb is not a solution - IS_ERR(root) is true in some cases when new_sb is true. Make sure new_sb is initialized (and matches the reality) in all cases and fix the condition for dropping kobj reference - we want it done precisely in those situations where the reference has not been transferred into a new super_block instance. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-21kernfs: deal with kernfs_fill_super() failuresAl Viro1-0/+1
make sure that info->node is initialized early, so that kernfs_kill_sb() can list_del() it safely. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-21cramfs: Fix IS_ENABLED typoJoe Perches1-1/+1
There's an extra C here... Fixes: 99c18ce580c6 ("cramfs: direct memory access support") Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-21befs_lookup(): use d_splice_alias()Al Viro1-12/+5
RTFS(Documentation/filesystems/nfs/Exporting) if you try to make something exportable. Fixes: ac632f5b6301 "befs: add NFS export support" Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-21affs_lookup: switch to d_splice_alias()Al Viro1-6/+5
Making something exportable takes more than providing ->s_export_ops. In particular, ->lookup() *MUST* use d_splice_alias() instead of d_add(). Reading Documentation/filesystems/nfs/Exporting would've been a good idea; as it is, exporting AFFS is badly (and exploitably) broken. Partially-Fixes: ed4433d72394 "fs/affs: make affs exportable" Acked-by: David Sterba <dsterba@suse.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-21affs_lookup(): close a race with affs_remove_link()Al Viro1-3/+7
we unlock the directory hash too early - if we are looking at secondary link and primary (in another directory) gets removed just as we unlock, we could have the old primary moved in place of the secondary, leaving us to look into freed entry (and leaving our dentry with ->d_fsdata pointing to a freed entry). Cc: stable@vger.kernel.org # 2.4.4+ Acked-by: David Sterba <dsterba@suse.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-17vfs: namei: use path_equal() in follow_dotdot()Danilo Krummrich1-3/+1
Use path_equal() to detect whether we're already in root. Signed-off-by: Danilo Krummrich <danilokrummrich@dk-develop.de> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-17fs.h: fix outdated comment about file flagsLi Qiang1-1/+1
The __dentry_open function was removed in commit <2a027e7a18738>("fold __dentry_open() into its sole caller"). Signed-off-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-14__inode_security_revalidate() never gets NULL opt_dentryAl Viro1-4/+3
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-14make xattr_getsecurity() staticAl Viro2-3/+1
many years overdue... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-13fix breakage caused by d_find_alias() semantics changeAl Viro1-4/+16
"VFS: don't keep disconnected dentries on d_anon" had a non-trivial side-effect - d_unhashed() now returns true for those dentries, making d_find_alias() skip them altogether. For most of its callers that's fine - we really want a connected alias there. However, there is a codepath where we relied upon picking such aliases if nothing else could be found - selinux delayed initialization of contexts for inodes on already mounted filesystems used to rely upon that. Cc: stable@kernel.org # f1ee616214cb "VFS: don't keep disconnected dentries on d_anon" Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-13vfat: simplify checks in vfat_lookup()Al Viro1-12/+1
vfat_d_anon_disconn() is called only if alias->d_parent is equal to dentry->d_parent *and* it returns false unless alias->d_parent == alias. But in that case alias is the directory we are doing lookup in, and d_splice_alias() would've done the right thing. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-13get rid of dead code in d_find_alias()Al Viro1-49/+34
All "try disconnected alias if nothing else fits" logics in d_find_alias() got accidentally disabled by Neil a while ago; for most of the callers it was the right thing to do, so fixes belong in few callers that *do* want disconnected aliases. This just takes the now-dead code in d_find_alias() out. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-11fs: don't scan the inode cache before SB_BORN is setDave Chinner1-6/+24
We recently had an oops reported on a 4.14 kernel in xfs_reclaim_inodes_count() where sb->s_fs_info pointed to garbage and so the m_perag_tree lookup walked into lala land. It produces an oops down this path during the failed mount: radix_tree_gang_lookup_tag+0xc4/0x130 xfs_perag_get_tag+0x37/0xf0 xfs_reclaim_inodes_count+0x32/0x40 xfs_fs_nr_cached_objects+0x11/0x20 super_cache_count+0x35/0xc0 shrink_slab.part.66+0xb1/0x370 shrink_node+0x7e/0x1a0 try_to_free_pages+0x199/0x470 __alloc_pages_slowpath+0x3a1/0xd20 __alloc_pages_nodemask+0x1c3/0x200 cache_grow_begin+0x20b/0x2e0 fallback_alloc+0x160/0x200 kmem_cache_alloc+0x111/0x4e0 The problem is that the superblock shrinker is running before the filesystem structures it depends on have been fully set up. i.e. the shrinker is registered in sget(), before ->fill_super() has been called, and the shrinker can call into the filesystem before fill_super() does it's setup work. Essentially we are exposed to both use-after-free and use-before-initialisation bugs here. To fix this, add a check for the SB_BORN flag in super_cache_count. In general, this flag is not set until ->fs_mount() completes successfully, so we know that it is set after the filesystem setup has completed. This matches the trylock_super() behaviour which will not let super_cache_scan() run if SB_BORN is not set, and hence will not allow the superblock shrinker from entering the filesystem while it is being set up or after it has failed setup and is being torn down. Cc: stable@kernel.org Signed-Off-By: Dave Chinner <dchinner@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-11do d_instantiate/unlock_new_inode combinations safelyAl Viro14-72/+57
For anything NFS-exported we do _not_ want to unlock new inode before it has grown an alias; original set of fixes got the ordering right, but missed the nasty complication in case of lockdep being enabled - unlock_new_inode() does lockdep_annotate_inode_mutex_key(inode) which can only be done before anyone gets a chance to touch ->i_mutex. Unfortunately, flipping the order and doing unlock_new_inode() before d_instantiate() opens a window when mkdir can race with open-by-fhandle on a guessed fhandle, leading to multiple aliases for a directory inode and all the breakage that follows from that. Correct solution: a new primitive (d_instantiate_new()) combining these two in the right order - lockdep annotate, then d_instantiate(), then the rest of unlock_new_inode(). All combinations of d_instantiate() with unlock_new_inode() should be converted to that. Cc: stable@kernel.org # 2.6.29 and later Tested-by: Mike Marshall <hubcap@omnibond.com> Reviewed-by: Andreas Dilger <adilger@dilger.ca> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-10it's SB_BORN, not MS_BORN...Al Viro1-1/+1
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-02iov_iter: fix memory leak in pipe_get_pages_alloc()Ilya Dryomov1-1/+1
Make n signed to avoid leaking the pages array if __pipe_get_pages() fails to allocate any pages. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-05-02iov_iter: fix return type of __pipe_get_pages()Ilya Dryomov1-1/+1
It returns -EFAULT and happens to be a helper for pipe_get_pages() whose return type is ssize_t. Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-04-20msdos_rmdir(): kill BS commentAl Viro1-4/+0
it hadn't been checking for "busy" since 2.3.99-something and removing that leaves us with "check if it's empty" followed by call of fat_dir_emtpy() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-04-19Don't leak MNT_INTERNAL away from internal mountsAl Viro1-1/+2
We want it only for the stuff created by SB_KERNMOUNT mounts, *not* for their copies. As it is, creating a deep stack of bindings of /proc/*/ns/* somewhere in a new namespace and exiting yields a stack overflow. Cc: stable@kernel.org Reported-by: Alexander Aring <aring@mojatatu.com> Bisected-by: Kirill Tkhai <ktkhai@virtuozzo.com> Tested-by: Kirill Tkhai <ktkhai@virtuozzo.com> Tested-by: Alexander Aring <aring@mojatatu.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-04-16remove rpc_rmdir()Al Viro2-18/+0
no users since 2014... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-04-16mm,vmscan: Allow preallocating memory for register_shrinker().Tetsuo Handa3-8/+29
syzbot is catching so many bugs triggered by commit 9ee332d99e4d5a97 ("sget(): handle failures of register_shrinker()"). That commit expected that calling kill_sb() from deactivate_locked_super() without successful fill_super() is safe, but the reality was different; some callers assign attributes which are needed for kill_sb() after sget() succeeds. For example, [1] is a report where sb->s_mode (which seems to be either FMODE_READ | FMODE_EXCL | FMODE_WRITE or FMODE_READ | FMODE_EXCL) is not assigned unless sget() succeeds. But it does not worth complicate sget() so that register_shrinker() failure path can safely call kill_block_super() via kill_sb(). Making alloc_super() fail if memory allocation for register_shrinker() failed is much simpler. Let's avoid calling deactivate_locked_super() from sget_userns() by preallocating memory for the shrinker and making register_shrinker() in sget_userns() never fail. [1] https://syzkaller.appspot.com/bug?id=588996a25a2587be2e3a54e8646728fb9cae44e7 Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reported-by: syzbot <syzbot+5a170e19c963a2e0df79@syzkaller.appspotmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Michal Hocko <mhocko@suse.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-04-15rpc_pipefs: fix double-dput()Al Viro1-0/+1
if we ever hit rpc_gssd_dummy_depopulate() dentry passed to it has refcount equal to 1. __rpc_rmpipe() drops it and dput() done after that hits an already freed dentry. Cc: stable@kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-04-15orangefs_kill_sb(): deal with allocation failuresAl Viro1-0/+5
orangefs_fill_sb() might've failed to allocate ORANGEFS_SB(s); don't oops in that case. Cc: stable@kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2018-04-15jffs2_kill_sb(): deal with failed allocationsAl Viro1-1/+1
jffs2_fill_super() might fail to allocate jffs2_sb_info; jffs2_kill_sb() must survive that. Cc: stable@kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>