Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 9月, 2021 1 次提交
  3. 04 9月, 2021 1 次提交
  5. 24 8月, 2021 10 次提交
  7. 23 8月, 2021 2 次提交
    • C
      namei: add mapping aware lookup helper · c2fd68b6
      由 Christian Brauner 提交于 
      Various filesystems rely on the lookup_one_len() helper to lookup a
single path component relative to a well-known starting point. Allow
such filesystems to support idmapped mounts by adding a version of this
helper to take the idmap into account when calling inode_permission().
This change is a required to let btrfs (and other filesystems) support
idmapped mounts.

Cc: Christoph Hellwig <hch@infradead.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: linux-fsdevel@vger.kernel.org
Reviewed-by: NJosef Bacik <josef@toxicpanda.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NChristian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: NDavid Sterba <dsterba@suse.com>
      c2fd68b6
    • J
      fs: remove mandatory file locking support · f7e33bdb
      由 Jeff Layton 提交于 
      We added CONFIG_MANDATORY_FILE_LOCKING in 2015, and soon after turned it
off in Fedora and RHEL8. Several other distros have followed suit.

I've heard of one problem in all that time: Someone migrated from an
older distro that supported "-o mand" to one that didn't, and the host
had a fstab entry with "mand" in it which broke on reboot. They didn't
actually _use_ mandatory locking so they just removed the mount option
and moved on.

This patch rips out mandatory locking support wholesale from the kernel,
along with the Kconfig option and the Documentation file. It also
changes the mount code to ignore the "mand" mount option instead of
erroring out, and to throw a big, ugly warning.
Signed-off-by: NJeff Layton <jlayton@kernel.org>
      f7e33bdb
  9. 08 4月, 2021 4 次提交
  11. 07 4月, 2021 2 次提交
    • A
      LOOKUP_MOUNTPOINT: we are cleaning "jumped" flag too late · 4f0ed93f
      由 Al Viro 提交于 
      That (and traversals in case of umount .) should be done before
complete_walk().  Either a braino or mismerge damage on queue
reorders - either way, I should've spotted that much earlier.
Fucked-up-by: NAl Viro <viro@zeniv.linux.org.uk>
X-Paperbag: Brown
Fixes: 161aff1d "LOOKUP_MOUNTPOINT: fold path_mountpointat() into path_lookupat()"
Cc: stable@vger.kernel.org # v5.7+
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      4f0ed93f
    • A
      Make sure nd->path.mnt and nd->path.dentry are always valid pointers · 7d01ef75
      由 Al Viro 提交于 
      Initialize them in set_nameidata() and make sure that terminate_walk() clears them
once the pointers become potentially invalid (i.e. we leave RCU mode or drop them
in non-RCU one).  Currently we have "path_init() always initializes them and nobody
accesses them outside of path_init()/terminate_walk() segments", which is asking
for trouble.

With that change we would have nd->path.{mnt,dentry}
	1) always valid - NULL or pointing to currently allocated objects.
	2) non-NULL while we are successfully walking
	3) NULL when we are not walking at all
	4) contributing to refcounts whenever non-NULL outside of RCU mode.

Fixes: 6c6ec2b0 ("fs: add support for LOOKUP_CACHED")
Reported-by: syzbot+c88a7030da47945a3cc3@syzkaller.appspotmail.com
Tested-by: NChristian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      7d01ef75
  13. 23 3月, 2021 3 次提交
  15. 21 2月, 2021 1 次提交
    • A
      fix handling of nd->depth on LOOKUP_CACHED failures in try_to_unlazy* · eacd9aa8
      由 Al Viro 提交于 
      After switching to non-RCU mode, we want nd->depth to match the number
of entries in nd->stack[] that need eventual path_put().
legitimize_links() takes care of that on failures; unfortunately,
failure exits added for LOOKUP_CACHED do not.

We could add the logics for that into those failure exits, both in
try_to_unlazy() and in try_to_unlazy_next(), but since both checks
are immediately followed by legitimize_links() and there's no calls
of legitimize_links() other than those two...  It's easier to
move the check (and required handling of nd->depth on failure) into
legitimize_links() itself.

[caught by Jens: ... and since we are zeroing ->depth here, we need
to do drop_links() first]

Fixes: 6c6ec2b0 "fs: add support for LOOKUP_CACHED"
Tested-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      eacd9aa8
  17. 24 1月, 2021 9 次提交
  19. 05 1月, 2021 3 次提交
    • J
      fs: add support for LOOKUP_CACHED · 6c6ec2b0
      由 Jens Axboe 提交于 
      io_uring always punts opens to async context, since there's no control
over whether the lookup blocks or not. Add LOOKUP_CACHED to support
just doing the fast RCU based lookups, which we know will not block. If
we can do a cached path resolution of the filename, then we don't have
to always punt lookups for a worker.

During path resolution, we always do LOOKUP_RCU first. If that fails and
we terminate LOOKUP_RCU, then fail a LOOKUP_CACHED attempt as well.

Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      6c6ec2b0
    • A
      saner calling conventions for unlazy_child() · ae66db45
      由 Al Viro 提交于 
      same as for the previous commit - instead of 0/-ECHILD make
it return true/false, rename to try_to_unlazy_child().
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      ae66db45
    • J
      fs: make unlazy_walk() error handling consistent · e36cffed
      由 Jens Axboe 提交于 
      Most callers check for non-zero return, and assume it's -ECHILD (which
it always will be). One caller uses the actual error return. Clean this
up and make it fully consistent, by having unlazy_walk() return a bool
instead. Rename it to try_to_unlazy() and return true on success, and
failure on error. That's easier to read.

No functional changes in this patch.

Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      e36cffed
  21. 04 1月, 2021 2 次提交
    • S
      fs/namei.c: Remove unlikely of status being -ECHILD in lookup_fast() · 26ddb45e
      由 Steven Rostedt (VMware) 提交于 
      Running my yearly branch profiling code, it detected a 100% wrong branch
condition in name.c for lookup_fast(). The code in question has:

		status = d_revalidate(dentry, nd->flags);
		if (likely(status > 0))
			return dentry;
		if (unlazy_child(nd, dentry, seq))
			return ERR_PTR(-ECHILD);
		if (unlikely(status == -ECHILD))
			/* we'd been told to redo it in non-rcu mode */
			status = d_revalidate(dentry, nd->flags);

If the status of the d_revalidate() is greater than zero, then the function
finishes. Otherwise, if it is an "unlazy_child" it returns with -ECHILD.
After the above two checks, the status is compared to -ECHILD, as that is
what is returned if the original d_revalidate() needed to be done in a
non-rcu mode.

Especially this path is called in a condition of:

	if (nd->flags & LOOKUP_RCU) {

And most of the d_revalidate() functions have:

	if (flags & LOOKUP_RCU)
		return -ECHILD;

It appears that that is the only case that this if statement is triggered
on two of my machines, running in production.

As it is dependent on what filesystem mix is configured in the running
kernel, simply remove the unlikely() from the if statement.
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      26ddb45e
    • A
      do_tmpfile(): don't mess with finish_open() · 1e8f44f1
      由 Al Viro 提交于 
      use vfs_open() instead
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      1e8f44f1
  23. 11 12月, 2020 1 次提交
  25. 10 12月, 2020 1 次提交