public inbox for linux-next@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Al Viro <viro@ZenIV.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	NeilBrown <neil@brown.name>, NeilBrown <neilb@suse.de>
Subject: linux-next: manual merge of the vfs tree with the vfs-brauner tree
Date: Fri, 16 May 2025 10:02:01 +1000	[thread overview]
Message-ID: <20250516100201.01a18903@canb.auug.org.au> (raw)

[-- Attachment #1: Type: text/plain, Size: 2892 bytes --]

Hi all,

Today's linux-next merge of the vfs tree got a conflict in:

  Documentation/filesystems/porting.rst

between commits:

  5741909697a3 ("VFS: improve interface for lookup_one functions")
  fa6fe07d1536 ("VFS: rename lookup_one_len family to lookup_noperm and remove permission check")
  06c567403ae5 ("Use try_lookup_noperm() instead of d_hash_and_lookup() outside of VFS")

from the vfs-brauner tree and commit:

  006ff7498fe8 ("saner calling conventions for ->d_automount()")

from the vfs tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/filesystems/porting.rst
index 3111ef5592f3,749637231773..000000000000
--- a/Documentation/filesystems/porting.rst
+++ b/Documentation/filesystems/porting.rst
@@@ -1206,40 -1206,7 +1206,46 @@@ will fail-safe
  
  ---
  
 +** mandatory**
 +
 +lookup_one(), lookup_one_unlocked(), lookup_one_positive_unlocked() now
 +take a qstr instead of a name and len.  These, not the "one_len"
 +versions, should be used whenever accessing a filesystem from outside
 +that filesysmtem, through a mount point - which will have a mnt_idmap.
 +
 +---
 +
 +** mandatory**
 +
 +Functions try_lookup_one_len(), lookup_one_len(),
 +lookup_one_len_unlocked() and lookup_positive_unlocked() have been
 +renamed to try_lookup_noperm(), lookup_noperm(),
 +lookup_noperm_unlocked(), lookup_noperm_positive_unlocked().  They now
 +take a qstr instead of separate name and length.  QSTR() can be used
 +when strlen() is needed for the length.
 +
 +For try_lookup_noperm() a reference to the qstr is passed in case the
 +hash might subsequently be needed.
 +
 +These function no longer do any permission checking - they previously
 +checked that the caller has 'X' permission on the parent.  They must
 +ONLY be used internally by a filesystem on itself when it knows that
 +permissions are irrelevant or in a context where permission checks have
 +already been performed such as after vfs_path_parent_lookup()
 +
 +---
 +
 +** mandatory**
 +
 +d_hash_and_lookup() is no longer exported or available outside the VFS.
 +Use try_lookup_noperm() instead.  This adds name validation and takes
 +arguments in the opposite order but is otherwise identical.
 +
 +Using try_lookup_noperm() will require linux/namei.h to be included.
 +
++---
++
+ **mandatory**
+ 
+ Calling conventions for ->d_automount() have changed; we should *not* grab
+ an extra reference to new mount - it should be returned with refcount 1.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

             reply	other threads:[~2025-05-16  0:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-16  0:02 Stephen Rothwell [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-04-08 12:43 linux-next: manual merge of the vfs tree with the vfs-brauner tree Mark Brown
2026-04-08 17:16 ` Al Viro
2026-04-08 17:32   ` Mark Brown
2026-01-19 13:45 Mark Brown
2026-01-14 22:38 Stephen Rothwell
2025-11-20 21:47 Stephen Rothwell
2025-11-20 21:42 Stephen Rothwell
2025-11-20 21:33 Stephen Rothwell
2025-11-20 21:27 Stephen Rothwell
2025-09-25 12:35 Mark Brown
2025-09-24  9:04 Mark Brown
2025-09-24  8:58 Mark Brown
2025-09-22  8:58 Mark Brown
2025-09-04 23:48 Stephen Rothwell
2025-07-07 23:38 Stephen Rothwell
2025-07-08  0:25 ` Al Viro
2025-07-08  0:45   ` Al Viro
2025-07-08  8:15     ` Christian Brauner
2025-01-19 23:41 Stephen Rothwell
2025-01-20  9:21 ` David Howells
2023-12-19 23:41 Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250516100201.01a18903@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=brauner@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=neilb@suse.de \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox