- 12 Oct, 2014 6 commits
-
-
Eric Biggers authored
This comment is 5 years outdated; init_file() no longer exists. Signed-off-by:
Eric Biggers <ebiggers3@gmail.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Eric Biggers authored
The following pairs of system calls dealing with extended attributes only differ in their behavior on whether the symbolic link is followed (when the named file is a symbolic link): - setxattr() and lsetxattr() - getxattr() and lgetxattr() - listxattr() and llistxattr() - removexattr() and lremovexattr() Despite this, the implementations all had duplicated code, so this commit redirects each of the above pairs of system calls to a corresponding function to which different lookup flags (LOOKUP_FOLLOW or 0) are passed. For me this reduced the stripped size of xattr.o from 8824 to 8248 bytes. Signed-off-by:
-
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
never used outside and it's too low-level for legitimate uses outside of fs/dcache.c anyway Signed-off-by: -
Al Viro authored
As it is, path_lookupat() and path_mounpoint() might end up leaking struct file reference in some cases. Spotted-by:
-
- 09 Oct, 2014 34 commits
-
-
Al Viro authored
we used to check for "nobody else could start doing anything with that opened file" by checking that refcount was 2 or less - one for descriptor table and one we'd acquired in fget() on the way to wherever we are. That was race-prone (somebody else might have had a reference to descriptor table and do fget() just as we'd been checking) and it had become flat-out incorrect back when we switched to fget_light() on those codepaths - unlike fget(), it doesn't grab an extra reference unless the descriptor table is shared. The same change allowed a race-free check, though - we are safe exactly when refcount is less than 2. It was a long time ago; pre-2.6.12 for ioctl() (the codepath leading to ppp one) and 2.6.17 for sendmsg() (netlink one). OTOH, netlink hadn't grown that check until 3.9 and ppp used to live in drivers/net, not drivers/net/ppp until 3.1. The bug existed well before that, though, and the same fix used to apply in old location of file. Cc: stable@vger.kernel.org Signed-off-by: -
Al Viro authored
Signed-off-by: -
Seunghun Lee authored
It would make more sense to pass char __user * instead of char * in callers of do_mount() and do getname() inside do_mount(). Suggested-by:
Seunghun Lee <waydi1@gmail.com> Signed-off-by:
-
Al Viro authored
hashed dentry can be passed to ->atomic_open() only if a) it has just passed revalidation and b) it's negative Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
return dentry, not inode. dev->inode is never used by anything, don't bother with storing it. Acked-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Al Viro authored
make it return dentry instead of inode Acked-by:
-
Al Viro authored
hlist_add_fake(inode->i_hash), same as for the rest of special ones... Signed-off-by: -
Al Viro authored
The only way we can get to that function is from misc_open(), after the latter has set file->f_op to exactly the same value we are (re)assigning there. Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Tim Gardner authored
The gcc version 4.9.1 compiler complains Even though it isn't possible for these variables to not get initialized before they are used. fs/namespace.c: In function ‘SyS_mount’: fs/namespace.c:2720:8: warning: ‘kernel_dev’ may be used uninitialized in this function [-Wmaybe-uninitialized] ret = do_mount(kernel_dev, kernel_dir->name, kernel_type, flags, ^ fs/namespace.c:2699:8: note: ‘kernel_dev’ was declared here char *kernel_dev; ^ fs/namespace.c:2720:8: warning: ‘kernel_type’ may be used uninitialized in this function [-Wmaybe-uninitialized] ret = do_mount(kernel_dev, kernel_dir->name, kernel_type, flags, ^ fs/namespace.c:2697:8: note: ‘kernel_type’ was declared here char *kernel_type; ^ Fix the warnings by simplifying copy_mount_string() as suggested by Al Viro. Cc: Alexander Viro <viro@zeniv.linux.org.uk> Signed-off-by:Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
Al Viro authored
That loop in there is both anti-idiomatic *and* completely pointless. strtoll() is there for purpose; use it and compare what's left with acceptable suffices. Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
... not to mention that even atomic_long_read() is too low-level here - there's file_count(). Signed-off-by: -
Al Viro authored
check with the author of that horror... Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
Signed-off-by: -
Mikulas Patocka authored
This patch makes it possible to kill a process looping in cont_expand_zero. A process may spend a lot of time in this function, so it is desirable to be able to kill it. It happened to me that I wanted to copy a piece data from the disk to a file. By mistake, I used the "seek" parameter to dd instead of "skip". Due to the "seek" parameter, dd attempted to extend the file and became stuck doing so - the only possibility was to reset the machine or wait many hours until the filesystem runs out of space and cont_expand_zero fails. We need this patch to be able to terminate the process. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Matthew Wilcox authored
For DAX, we want to be able to copy between iovecs and kernel addresses that don't necessarily have a struct page. This is a fairly simple rearrangement for bvec iters to kmap the pages outside and pass them in, but for user iovecs it gets more complicated because we might try various different ways to kmap the memory. Duplicating the existing logic works out best in this case. We need to be able to write zeroes to an iovec for reads from unwritten ranges in a file. This is performed by the new iov_iter_zero() function, again patterned after the existing code that handles iovec iterators. [AV: and export the buggers...] Signed-off-by:
Matthew Wilcox <willy@linux.intel.com> Signed-off-by:
-
Tetsuo Handa authored
total_objects could be 0 and is used as a denom. While total_objects is a "long", total_objects == 0 unlikely happens for 3.12 and later kernels because 32-bit architectures would not be able to hold (1 << 32) objects. However, total_objects == 0 may happen for kernels between 3.1 and 3.11 because total_objects in prune_super() was an "int" and (e.g.) x86_64 architecture might be able to hold (1 << 32) objects. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by:
Christoph Hellwig <hch@lst.de> Cc: stable <stable@kernel.org> # 3.1+ Signed-off-by:
-
Daeseok Youn authored
Fixed coding style in dcache.c Signed-off-by:
Daeseok Youn <daeseok.youn@gmail.com> Signed-off-by:
-
Al Viro authored
schedule_delayed_work() happening when the work is already pending is a cheap no-op. Don't bother with ->wbuf_queued logics - it's both broken (cancelling ->wbuf_dwork leaves it set, as spotted by Jeff Harris) and pointless. It's cheaper to let schedule_delayed_work() handle that case. Reported-by:
Jeff Harris <jefftharris@gmail.com> Tested-by:
-
Kirill Smelkov authoredThe function which calls s_op->alloc_inode() is not inode_alloc(), but instead alloc_inode() which lives in fs/inode.c . The typo was there from the beginning from 5ea626aa (VFS: update documentation, 2005) - there was no standalone inode_alloc() for the whole kernel history. Cc: Pekka Enberg <penberg@kernel.org> Signed-off-by:
Kirill Smelkov <kirr@nexedi.com>
Signed-off-by:
-
