public inbox for linux-next@vger.kernel.org 
 help / color / mirror / Atom feed
* linux-next: manual merge of the vfs-brauner tree with the nfsd tree
@ 2025-11-16 20:34 Stephen Rothwell
  2025-12-02 23:11 ` Stephen Rothwell
  0 siblings, 1 reply; 12+ messages in thread
From: Stephen Rothwell @ 2025-11-16 20:34 UTC (permalink / raw)
  To: Christian Brauner, Chuck Lever
  Cc: Jeff Layton, Linux Kernel Mailing List, Linux Next Mailing List,
	NeilBrown, NeilBrown

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

Hi all,

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

  fs/nfsd/nfs4recover.c

between commit:

  8a25e05a98ab ("nfsd: move name lookup out of nfsd4_list_rec_dir()")

from the nfsd tree and commit:

  4fa76319cd0c ("vfs: allow rmdir to wait for delegation break on parent")

from the vfs-brauner 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 fs/nfsd/nfs4recover.c
index b1005abcb903,1f031e5af5b2..000000000000
--- a/fs/nfsd/nfs4recover.c
+++ b/fs/nfsd/nfs4recover.c
@@@ -201,18 -210,17 +199,16 @@@ nfsd4_create_clid_dir(struct nfs4_clien
  		 * In the 4.0 case, we should never get here; but we may
  		 * as well be forgiving and just succeed silently.
  		 */
- 		goto out_put;
- 	dentry = vfs_mkdir(&nop_mnt_idmap, d_inode(dir), dentry, S_IRWXU);
+ 		goto out_end;
+ 	dentry = vfs_mkdir(&nop_mnt_idmap, d_inode(dir), dentry, S_IRWXU, NULL);
  	if (IS_ERR(dentry))
  		status = PTR_ERR(dentry);
- out_put:
- 	if (!status)
- 		dput(dentry);
- out_unlock:
- 	inode_unlock(d_inode(dir));
+ out_end:
+ 	end_creating(dentry);
+ out:
  	if (status == 0) {
  		if (nn->in_grace)
 -			__nfsd4_create_reclaim_record_grace(clp, dname,
 -					HEXDIR_LEN, nn);
 +			__nfsd4_create_reclaim_record_grace(clp, dname, nn);
  		vfs_fsync(nn->rec_file, 0);
  	} else {
  		printk(KERN_ERR "NFSD: failed to write recovery record"
@@@ -406,17 -415,10 +394,17 @@@ purge_old(struct dentry *parent, char *
  	if (nfs4_has_reclaimed_state(name, nn))
  		goto out_free;
  
 -	status = vfs_rmdir(&nop_mnt_idmap, d_inode(parent), child, NULL);
 -	if (status)
 -		printk("failed to remove client recovery directory %pd\n",
 -				child);
 +	inode_lock_nested(d_inode(parent), I_MUTEX_PARENT);
 +	child = lookup_one(&nop_mnt_idmap, &QSTR(cname), parent);
 +	if (!IS_ERR(child)) {
- 		status = vfs_rmdir(&nop_mnt_idmap, d_inode(parent), child);
++		status = vfs_rmdir(&nop_mnt_idmap, d_inode(parent), child, NULL);
 +		if (status)
 +			printk("failed to remove client recovery directory %pd\n",
 +			       child);
 +		dput(child);
 +	}
 +	inode_unlock(d_inode(parent));
 +
  out_free:
  	kfree(name.data);
  out:

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

^ permalink raw reply	[flat|nested] 12+ messages in thread
* linux-next: manual merge of the vfs-brauner tree with the nfsd tree
@ 2026-05-28 14:28 Mark Brown
  2026-05-28 14:51 ` Chuck Lever
  0 siblings, 1 reply; 12+ messages in thread
From: Mark Brown @ 2026-05-28 14:28 UTC (permalink / raw)
  To: Christian Brauner, Chuck Lever
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

Today's linux-next merge of the vfs-brauner tree got conflicts in:

  kernel/ptrace.c
  fs/exec.c
  include/linux/binfmts.h
  kernel/exec_state.c

between commits:

  6b1c66c9cca99 ("exec_state: relocate dumpable information")
  38205ecbe6b6d ("exec: free the old mm outside the exec locks")

from the nfsd tree and commits:

  6b1c66c9cca99 ("exec_state: relocate dumpable information")
  38205ecbe6b6d ("exec: free the old mm outside the exec locks")

from the vfs-brauner tree plus some other context from vfs-brauner
merges.  Specifically this is due to the nfsd tree having a build break
from the vfs-brauner tree it's based on and being held at an old version
with it's old version of vfs-brauner while the vfs-brauner tree has been
updated.  However since the build issue isn't fixed in the version of
vfs-brauner I have today (I saw a patch on the list though, I guess this
will be fixed tomorrow?) the below merge isn't actually going to be in
-next, I'm merging the old version that's shared with nfsd and there's
no actual conflict in today's tree.

Are you sure it's a good idea to base the nfsd tree on something
that's rebasing?

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.

diff --combined fs/exec.c
index 894added369dd,b92fe7db176cf..0000000000000
--- a/fs/exec.c
+++ b/fs/exec.c
@@@ -836,16 -836,18 +836,18 @@@ EXPORT_SYMBOL(read_code)
  /*
   * Maps the mm_struct mm into the current task struct.
   * On success, this function returns with exec_update_lock
-  * held for writing.
+  * held for writing. The replaced address space is stashed in
+  * bprm->old_mm for setup_new_exec() to release outside the lock.
   */
- static int exec_mmap(struct mm_struct *mm, struct user_namespace *user_ns)
+ static int exec_mmap(struct linux_binprm *bprm)
  {
  	struct task_exec_state *exec_state __free(put_task_exec_state) = NULL;
+ 	struct mm_struct *mm = bprm->mm;
  	struct task_struct *tsk;
  	struct mm_struct *old_mm, *active_mm;
  	int ret;
  
- 	exec_state = alloc_task_exec_state(user_ns);
+ 	exec_state = alloc_task_exec_state(bprm->user_ns);
  	if (!exec_state)
  		return -ENOMEM;
  
@@@ -898,15 -900,22 +900,22 @@@
  	if (old_mm) {
  		mmap_read_unlock(old_mm);
  		BUG_ON(active_mm != old_mm);
- 		setmax_mm_hiwater_rss(&tsk->signal->maxrss, old_mm);
- 		mm_update_next_owner(old_mm);
- 		mmput(old_mm);
+ 		/* Defer teardown to setup_new_exec(), outside the exec locks. */
+ 		bprm->old_mm = old_mm;
  		return 0;
  	}
  	mmdrop_lazy_tlb(active_mm);
  	return 0;
  }
  
+ /* Release the address space replaced by exec, outside the exec locks. */
+ static void exec_mm_put_old(struct mm_struct *old_mm)
+ {
+ 	setmax_mm_hiwater_rss(&current->signal->maxrss, old_mm);
+ 	mm_update_next_owner(old_mm);
+ 	mmput(old_mm);
+ }
+ 
  static int de_thread(struct task_struct *tsk)
  {
  	struct signal_struct *sig = tsk->signal;
@@@ -1155,7 -1164,7 +1164,7 @@@ int begin_new_exec(struct linux_binprm 
  	 * Release all of the old mmap stuff
  	 */
  	acct_arg_size(bprm, 0);
- 	retval = exec_mmap(bprm->mm, bprm->user_ns);
+ 	retval = exec_mmap(bprm);
  	if (retval)
  		goto out;
  
@@@ -1338,6 -1347,12 +1347,12 @@@ void setup_new_exec(struct linux_binpr
  	me->mm->task_size = TASK_SIZE;
  	up_write(&me->signal->exec_update_lock);
  	mutex_unlock(&me->signal->cred_guard_mutex);
+ 
+ 	/* The exec locks are dropped: release the old address space now. */
+ 	if (bprm->old_mm) {
+ 		exec_mm_put_old(bprm->old_mm);
+ 		bprm->old_mm = NULL;
+ 	}
  }
  EXPORT_SYMBOL(setup_new_exec);
  
@@@ -1394,6 -1409,9 +1409,9 @@@ static void free_bprm(struct linux_binp
  		mutex_unlock(&current->signal->cred_guard_mutex);
  		abort_creds(bprm->cred);
  	}
+ 	/* exec swapped the mm but failed before setup_new_exec() freed it */
+ 	if (bprm->old_mm)
+ 		exec_mm_put_old(bprm->old_mm);
  	do_close_execat(bprm->file);
  	if (bprm->executable)
  		fput(bprm->executable);
diff --combined include/linux/binfmts.h
index a8379f4eee615,2c77e383e7375..0000000000000
--- a/include/linux/binfmts.h
+++ b/include/linux/binfmts.h
@@@ -25,6 -25,7 +25,7 @@@ struct linux_binprm 
  	struct page *page[MAX_ARG_PAGES];
  #endif
  	struct mm_struct *mm;
+ 	struct mm_struct *old_mm;	/* replaced address space, freed by setup_new_exec() */
  	/* user_ns published to task->exec_state at execve, narrowed by would_dump(). */
  	struct user_namespace *user_ns;
  	unsigned long p; /* current top of mem */
diff --combined kernel/exec_state.c
index 2b7d0262d0f4e,6034f4b4808fe..0000000000000
--- a/kernel/exec_state.c
+++ b/kernel/exec_state.c
@@@ -91,7 -91,7 +91,7 @@@ void task_exec_state_set_dumpable(enum 
  {
  	struct task_exec_state *exec_state;
  
- 	if (WARN_ON(value > TASK_DUMPABLE_ROOT))
+ 	if (WARN_ON_ONCE(value > TASK_DUMPABLE_ROOT))
  		value = TASK_DUMPABLE_OFF;
  
  	exec_state = rcu_dereference_protected(current->exec_state, true);
diff --combined kernel/ptrace.c
index ea8a682e837d9,d041645d9d17d..0000000000000
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@@ -53,11 -53,9 +53,9 @@@ bool ptracer_access_allowed(struct task
  {
  	const struct task_exec_state *es;
  
- 	if (!tsk->ptrace)
- 		return false;
- 	if (current != tsk->parent)
- 		return false;
  	guard(rcu)();
+ 	if (ptrace_parent(tsk) != current)
+ 		return false;
  	es = task_exec_state_rcu(tsk);
  	return READ_ONCE(es->dumpable) == TASK_DUMPABLE_OWNER ||
  	       ptracer_capable(tsk, es->user_ns);


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

^ permalink raw reply	[flat|nested] 12+ messages in thread
* linux-next: manual merge of the vfs-brauner tree with the nfsd tree
@ 2024-10-23 21:15 Stephen Rothwell
  0 siblings, 0 replies; 12+ messages in thread
From: Stephen Rothwell @ 2024-10-23 21:15 UTC (permalink / raw)
  To: Christian Brauner, Chuck Lever
  Cc: Benjamin Coddington, Linux Kernel Mailing List,
	Linux Next Mailing List, Mike Snitzer

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

Hi all,

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

  include/linux/exportfs.h

between commit:

  6e99e4b4291e ("nfsd: disallow file locking and delegations for NFSv4 reexport")

from the nfsd tree and commit:

  b875bd5b381e ("exportfs: Remove EXPORT_OP_ASYNC_LOCK")

from the vfs-brauner 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 include/linux/exportfs.h
index 106fd590d323,4cc8801e50e3..000000000000
--- a/include/linux/exportfs.h
+++ b/include/linux/exportfs.h
@@@ -251,32 -263,6 +264,19 @@@ struct export_operations 
  	unsigned long	flags;
  };
  
- /**
-  * exportfs_lock_op_is_async() - export op supports async lock operation
-  * @export_ops:	the nfs export operations to check
-  *
-  * Returns true if the nfs export_operations structure has
-  * EXPORT_OP_ASYNC_LOCK in their flags set
-  */
- static inline bool
- exportfs_lock_op_is_async(const struct export_operations *export_ops)
- {
- 	return export_ops->flags & EXPORT_OP_ASYNC_LOCK;
- }
- 
 +/**
 + * exportfs_lock_op_is_unsupported() - export does not support file locking
 + * @export_ops:	the nfs export operations to check
 + *
 + * Returns true if the nfs export_operations structure has
 + * EXPORT_OP_NOLOCKSUPPORT in their flags set
 + */
 +static inline bool
 +exportfs_lock_op_is_unsupported(const struct export_operations *export_ops)
 +{
 +	return export_ops->flags & EXPORT_OP_NOLOCKSUPPORT;
 +}
 +
  extern int exportfs_encode_inode_fh(struct inode *inode, struct fid *fid,
  				    int *max_len, struct inode *parent,
  				    int flags);

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

^ permalink raw reply	[flat|nested] 12+ messages in thread
* linux-next: manual merge of the vfs-brauner tree with the nfsd tree
@ 2024-02-07  0:41 Stephen Rothwell
  2024-02-07 14:40 ` Chuck Lever
  0 siblings, 1 reply; 12+ messages in thread
From: Stephen Rothwell @ 2024-02-07  0:41 UTC (permalink / raw)
  To: Christian Brauner, Chuck Lever
  Cc: Jeff Layton, Linux Kernel Mailing List, Linux Next Mailing List,
	NeilBrown

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

Hi all,

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

  fs/nfsd/nfs4layouts.c

between commit:

  b1f1961080c4 ("nfsd: allow layout state to be admin-revoked.")

from the nfsd tree and commit:

  7b8001013d72 ("filelock: don't do security checks on nfsd setlease calls")

from the vfs-brauner 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 fs/nfsd/nfs4layouts.c
index b1e585c1d9a3,4c0d00bdfbb1..4f3072b5979a
--- a/fs/nfsd/nfs4layouts.c
+++ b/fs/nfsd/nfs4layouts.c
@@@ -152,23 -152,6 +152,23 @@@ void nfsd4_setup_layout_type(struct svc
  #endif
  }
  
 +void nfsd4_close_layout(struct nfs4_layout_stateid *ls)
 +{
 +	struct nfsd_file *fl;
 +
 +	spin_lock(&ls->ls_stid.sc_file->fi_lock);
 +	fl = ls->ls_file;
 +	ls->ls_file = NULL;
 +	spin_unlock(&ls->ls_stid.sc_file->fi_lock);
 +
 +	if (fl) {
 +		if (!nfsd4_layout_ops[ls->ls_layout_type]->disable_recalls)
- 			vfs_setlease(fl->nf_file, F_UNLCK, NULL,
- 				     (void **)&ls);
++			kernel_setlease(fl->nf_file, F_UNLCK, NULL,
++					(void **)&ls);
 +		nfsd_file_put(fl);
 +	}
 +}
 +
  static void
  nfsd4_free_layout_stateid(struct nfs4_stid *stid)
  {

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

^ permalink raw reply	[flat|nested] 12+ messages in thread
* linux-next: manual merge of the vfs-brauner tree with the nfsd tree
@ 2023-05-23 23:56 Stephen Rothwell
  2023-05-24  9:08 ` Christian Brauner
  0 siblings, 1 reply; 12+ messages in thread
From: Stephen Rothwell @ 2023-05-23 23:56 UTC (permalink / raw)
  To: Christian Brauner, Chuck Lever
  Cc: Amir Goldstein, J. Bruce Fields, Jeff Layton,
	Linux Kernel Mailing List, Linux Next Mailing List

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

Hi all,

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

  fs/nfsd/nfsfh.c

between commit:

  fed41678532c ("nfsd: don't provide pre/post-op attrs if fh_getattr fails")

from the nfsd tree and commit:

  1a6f4cbffdf5 ("nfsd: ensure we use ctime_peek to grab the inode->i_ctime")

from the vfs-brauner tree.

I fixed it up (I just used the version from the nsfd tree - which
removed the code modified by the latter) 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

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

^ permalink raw reply	[flat|nested] 12+ messages in thread
end of thread, other threads:[~2026-05-28 15:35 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-16 20:34 linux-next: manual merge of the vfs-brauner tree with the nfsd tree Stephen Rothwell
2025-12-02 23:11 ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2026-05-28 14:28 Mark Brown
2026-05-28 14:51 ` Chuck Lever
2026-05-28 15:01   ` Mark Brown
2026-05-28 15:34     ` Chuck Lever
2024-10-23 21:15 Stephen Rothwell
2024-02-07  0:41 Stephen Rothwell
2024-02-07 14:40 ` Chuck Lever
2024-02-07 14:58   ` Jeff Layton
2023-05-23 23:56 Stephen Rothwell
2023-05-24  9:08 ` Christian Brauner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox