- 18 Jul, 2018 16 commits
-
-
Miklos Szeredi authored
Implement stacked mmap. Signed-off-by:Miklos Szeredi <mszeredi@redhat.com>
-
Miklos Szeredi authored
Implement stacked fsync(). Don't sync if lower (noticed by Amir Goldstein). Signed-off-by: -
Miklos Szeredi authored
Implement stacked writes. Signed-off-by: -
Miklos Szeredi authored
Implement stacked reading. Signed-off-by: -
Miklos Szeredi authored
In the common case we can just use the real file cached in file->private_data. There are two exceptions: 1) File has been copied up since open: in this unlikely corner case just use a throwaway real file for the operation. If ever this becomes a perfomance problem (very unlikely, since overlayfs has been doing most fine without correctly handling this case at all), then we can deal with that by updating the cached real file. 2) File's f_flags have changed since open: no need to reopen the cached real file, we can just change the flags there as well. Signed-off-by: -
Miklos Szeredi authored
Implement file operations on a regular overlay file. The underlying file is opened separately and cached in ->private_data. It might be worth making an exception for such files when accounting in nr_file to confirm to userspace expectations. We are only adding a small overhead (248bytes for the struct file) since the real inode and dentry are pinned by overlayfs anyway. This patch doesn't have any effect, since the vfs will use d_real() to find the real underlying file to open. The patch at the end of the series will actually enable this functionality. AV: make it use open_with_fake_path(), don't mess with override_creds SzM: still need to mess with override_creds() until no fs uses current_cred() in their open method. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Miklos Szeredi authored
Signed-off-by: -
Miklos Szeredi authored
Copy i_size of the underlying inode to the overlay inode in ovl_copyattr(). This is in preparation for stacking I/O operations on overlay files. This patch shouldn't have any observable effect. Remove stale comment from ovl_setattr() [spotted by Vivek Goyal]. Signed-off-by: -
Miklos Szeredi authored
This reverts commit 31c3a706. Re-add functionality dealing with i_writecount on truncate to overlayfs. This patch shouldn't have any observable effects, since we just re-assert the writecout that vfs_truncate() already got for us. This is in preparation for moving overlay functionality out of the VFS. Signed-off-by:
-
Miklos Szeredi authored
On inode creation copy certain inode flags from the underlying real inode to the overlay inode. This is in preparation for moving overlay functionality out of the VFS. Signed-off-by: -
Miklos Szeredi authored
Copy up mtime and ctime to overlay inode after times in real object are modified. Be careful not to dirty cachelines when not necessary. This is in preparation for moving overlay functionality out of the VFS. This patch shouldn't have any observable effect. Signed-off-by: -
Miklos Szeredi authored
This is needed by the stacked dedupe implementation in overlayfs. Signed-off-by: -
Miklos Szeredi authored
This is needed by the stacked ioctl implementation in overlayfs. Signed-off-by: -
Miklos Szeredi authored
Stacking file operations in overlay will store an extra open file for each overlay file opened. The overhead is just that of "struct file" which is about 256bytes, because overlay already pins an extra dentry and inode when the file is open, which add up to a much larger overhead. For fear of breaking working setups, don't start accounting the extra file. Signed-off-by: -
Miklos Szeredi authored
Following series for stacking overlay files depends on this mini series.
-
Miklos Szeredi authored
Merge branch 'for-ovl' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs into overlayfs-next This gives us the open_with_fake_path() helper that is needed for stacked open files in overlay and mmap in particular.
-
- 17 Jul, 2018 1 commit
-
-
Amir Goldstein authored
Only upper dir can be impure, but if we are in the middle of iterating a lower real dir, dir could be copied up and marked impure. We only want the impure cache if we started iterating a real upper dir to begin with. Aditya Kali reported that the following reproducer hits the WARN_ON(!cache->refcount) in ovl_get_cache(): docker run --rm drupal:8.5.4-fpm-alpine \ sh -c 'cd /var/www/html/vendor/symfony && \ chown -R www-data:www-data . && ls -l .' Reported-by:Aditya Kali <adityakali@google.com> Tested-by:
Amir Goldstein <amir73il@gmail.com> Signed-off-by:
-
- 12 Jul, 2018 11 commits
-
-
Al Viro authored
open a file by given inode, faking ->f_path. Use with shitloads of caution - at the very least you'd damn better make sure that some dentry alias of that inode is pinned down by the path in question. Again, this is no general-purpose interface and I hope it will eventually go away. Right now overlayfs wants something like that, but nothing else should. Any out-of-tree code with bright idea of using this one *will* eventually get hurt, with zero notice and great delight on my part. I refuse to use EXPORT_SYMBOL_GPL(), especially in situations when it's really EXPORT_SYMBOL_DONT_USE_IT(), but don't take that export as "you are welcome to use it". Signed-off-by: -
Al Viro authored
These checks are better off in do_dentry_open(); the reason we couldn't put them there used to be that callers couldn't tell what kind of cleanup would do_dentry_open() failure call for. Now that we have FMODE_OPENED, cleanup is the same in all cases - it's simply fput(). So let's fold that into do_dentry_open(), as Christoph's patch tried to. Acked-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Al Viro authored
Acked-by:
-
Al Viro authored
Just check FMODE_OPENED in __fput() and be done with that... Acked-by:
-
Al Viro authored
basically, "is that instance set up enough for regular fput(), or do we want put_filp() for that one". NOTE: the only alloc_file() caller that could be followed by put_filp() is in arch/ia64/kernel/perfmon.c, which is (Kconfig-level) broken. Acked-by:
-
Al Viro authored
Acked-by:
-
Al Viro authored
Acked-by:
-
Al Viro authored
always equal to ->f_cred Acked-by:
-
Al Viro authored
... and have it set the f_flags-derived part of ->f_mode. Signed-off-by: -
Al Viro authored
... and rename get_empty_filp() to alloc_empty_file(). dentry_open() gets creds as argument, but the only thing that sees those is security_file_open() - file->f_cred still ends up with current_cred(). For almost all callers it's the same thing, but there are several broken cases. Acked-by:
-
Al Viro authored
... so that it could set both ->f_flags and ->f_mode, without callers having to set ->f_flags manually. Signed-off-by:
-
- 11 Jul, 2018 7 commits
-
-
Al Viro authored
An ->open() instances really, really should not be doing that. There's a lot of places e.g. around atomic_open() that could be confused by that, so let's catch that early. Acked-by:
-
Al Viro authored
... just use put_pipe_info() to get the pipe->files down to 1 and let fput()-called pipe_release() do freeing. Acked-by:
-
Al Viro authored
it's exactly the same thing as dentry_open(&file->f_path, file->f_flags, file->f_cred) ... and rename it to file_clone_open(), while we are at it. 'filp' naming convention is bogus; sure, it's "file pointer", but we generally don't do that kind of Hungarian notation. Some of the instances have too many callers to touch, but this one has only two, so let's sanitize it while we can... Acked-by:
-
Al Viro authored
.. and the call of file_free() in case of security_file_alloc() failure in get_empty_filp() should be simply file_free_rcu() - no point in rcu-delays there, anyway. Acked-by:
-
Al Viro authored
Cc: stable@vger.kernel.org Acked-by:
-
Al Viro authored
Doing iput() after path_put() is wrong. Cc: stable@vger.kernel.org Acked-by:
-
Al Viro authored
Failure of ->open() should *not* be followed by fput(). Fixed by using filp_clone_open(), which gets the cleanups right. Cc: stable@vger.kernel.org Acked-by:
-
- 06 Jul, 2018 4 commits
-
-
Miklos Szeredi authored
Extract vfs_dedupe_file_range_one() helper to deal with a single dedup request. Signed-off-by:
Christoph Hellwig <hch@lst.de>
-
Miklos Szeredi authored
Clean up f_op->dedupe_file_range() interface. 1) Use loff_t for offsets and length instead of u64 2) Order the arguments the same way as {copy|clone}_file_range(). Signed-off-by:Darrick J. Wong <darrick.wong@oracle.com>
-
Miklos Szeredi authored
Signed-off-by: -
Miklos Szeredi authored
Suggested-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
-
- 28 Jun, 2018 1 commit
-
-
Chunyu Hu authored
kmemleak reported some memory leak on reading proc files. After adding some debug lines, find that proc_seq_fops is using seq_release as release handler, which won't handle the free of 'private' field of seq_file, while in fact the open handler proc_seq_open could create the private data with __seq_open_private when state_size is greater than zero. So after reading files created with proc_create_seq_private, such as /proc/timer_list and /proc/vmallocinfo, the private mem of a seq_file is not freed. Fix it by adding the paired proc_seq_release as the default release handler of proc_seq_ops instead of seq_release. Fixes: 44414d82 ("proc: introduce proc_create_seq_private") Reviewed-by:
Chunyu Hu <chuhu@redhat.com> Signed-off-by:
-
