* 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
* Re: 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, 0 replies; 12+ messages in thread
From: Christian Brauner @ 2023-05-24 9:08 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Chuck Lever, Amir Goldstein, J. Bruce Fields, Jeff Layton,
Linux Kernel Mailing List, Linux Next Mailing List
On Wed, May 24, 2023 at 09:56:14AM +1000, Stephen Rothwell wrote:
> 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.
I'll drop Jeff's series from vfs.all since he's about to send a new
version anyway. Thanks!
^ 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
* Re: linux-next: manual merge of the vfs-brauner tree with the nfsd tree
2024-02-07 0:41 linux-next: manual merge of the vfs-brauner tree with the nfsd tree Stephen Rothwell
@ 2024-02-07 14:40 ` Chuck Lever
2024-02-07 14:58 ` Jeff Layton
0 siblings, 1 reply; 12+ messages in thread
From: Chuck Lever @ 2024-02-07 14:40 UTC (permalink / raw)
To: Christian Brauner, Jeff Layton
Cc: Linux Kernel Mailing List, Linux Next Mailing List, NeilBrown
On Wed, Feb 07, 2024 at 11:41:18AM +1100, Stephen Rothwell wrote:
> 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.
Christian, Jeff -
For the remaining duration of v6.9 development, should I rebase
nfsd-next on vfs-brauner ?
> 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)
> {
--
Chuck Lever
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the vfs-brauner tree with the nfsd tree
2024-02-07 14:40 ` Chuck Lever
@ 2024-02-07 14:58 ` Jeff Layton
0 siblings, 0 replies; 12+ messages in thread
From: Jeff Layton @ 2024-02-07 14:58 UTC (permalink / raw)
To: Chuck Lever, Christian Brauner
Cc: Linux Kernel Mailing List, Linux Next Mailing List, NeilBrown
On Wed, 2024-02-07 at 09:40 -0500, Chuck Lever wrote:
> On Wed, Feb 07, 2024 at 11:41:18AM +1100, Stephen Rothwell wrote:
> > 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.
>
> Christian, Jeff -
>
> For the remaining duration of v6.9 development, should I rebase
> nfsd-next on vfs-brauner ?
>
IMO, no. The fixup is pretty small. A vfs_setlease call got moved in
your tree in one of Neil's patches, so the merge just needs to account
for that when we're doing s/vfs_setlease/kernel_setlease/ in that file.
>
> > 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)
> > {
>
>
>
--
Jeff Layton <jlayton@kernel•org>
^ 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
@ 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
* Re: 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, 0 replies; 12+ messages in thread
From: Stephen Rothwell @ 2025-12-02 23:11 UTC (permalink / raw)
To: Chuck Lever
Cc: Christian Brauner, Jeff Layton, Linux Kernel Mailing List,
Linux Next Mailing List, NeilBrown, NeilBrown
[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]
Hi all,
On Mon, 17 Nov 2025 07:34:52 +1100 Stephen Rothwell <sfr@canb•auug.org.au> wrote:
>
> 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.
>
>
> 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:
This is now a conflict between the nfsd tree and Linus' tree.
--
Cheers,
Stephen Rothwell
[-- 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(¤t->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(¤t->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
* Re: 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
2026-05-28 15:01 ` Mark Brown
0 siblings, 1 reply; 12+ messages in thread
From: Chuck Lever @ 2026-05-28 14:51 UTC (permalink / raw)
To: Mark Brown, Christian Brauner, Jeff Layton
Cc: Linux Kernel Mailing List, Linux Next Mailing List
On 5/28/26 10:28 AM, Mark Brown wrote:
> 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?
Usually nfsd-next is based on a torvalds -rc tag. This time around,
Christian wanted to take some patches through the vfs tree that I need
for nfsd-7.2. Therefore I need to base nfsd-next on a branch that is a
merge of several vfs. topic branches plus the latest -rc tag.
vfs/vfs.all is the most convenient source of such a merged branch,
but it has proved unstable (yes, I was warned it might be!).
So I can think of a few alternate options:
1. I might create my own merged branch that grabs only the three vfs.
branches I need. Cons: I've never done this before, I'm not certain
my tool chain (StGit) supports git merge, and it tangles the merge
graph even more than it already is.
2. I might drop the items in nfsd-next/testing that need the vfs.
branches, and rebase nfsd-next on a torvalds -rc tag. Cons: that
leaves the pre-requisites in vfs.all but they won't get an in-kernel
consumer until v7.3
3. Maybe the only branch I need is the vfs.directory-delegation branch?
I might rebase nfsd-next on that. But I still need -rc latest for
patches in nfsd-testing to apply cleanly to nfsd-next.
Opinions are welcome! I'll start: I really dislike cross-tree
submission; it's a pain for everyone for not very much benefit. :-)
--
Chuck Lever
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the vfs-brauner tree with the nfsd tree
2026-05-28 14:51 ` Chuck Lever
@ 2026-05-28 15:01 ` Mark Brown
2026-05-28 15:34 ` Chuck Lever
0 siblings, 1 reply; 12+ messages in thread
From: Mark Brown @ 2026-05-28 15:01 UTC (permalink / raw)
To: Chuck Lever
Cc: Christian Brauner, Jeff Layton, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
On Thu, May 28, 2026 at 10:51:58AM -0400, Chuck Lever wrote:
> 1. I might create my own merged branch that grabs only the three vfs.
> branches I need. Cons: I've never done this before, I'm not certain
> my tool chain (StGit) supports git merge, and it tangles the merge
> graph even more than it already is.
You could always create this independently of your usual tooling and use
it as a base like something that someone else had created? I don't know
StGit but I have similar stuff with my own tooling sometimes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the vfs-brauner tree with the nfsd tree
2026-05-28 15:01 ` Mark Brown
@ 2026-05-28 15:34 ` Chuck Lever
0 siblings, 0 replies; 12+ messages in thread
From: Chuck Lever @ 2026-05-28 15:34 UTC (permalink / raw)
To: Mark Brown
Cc: Christian Brauner, Jeff Layton, Linux Kernel Mailing List,
Linux Next Mailing List
On 5/28/26 11:01 AM, Mark Brown wrote:
> On Thu, May 28, 2026 at 10:51:58AM -0400, Chuck Lever wrote:
>
>> 1. I might create my own merged branch that grabs only the three vfs.
>> branches I need. Cons: I've never done this before, I'm not certain
>> my tool chain (StGit) supports git merge, and it tangles the merge
>> graph even more than it already is.
>
> You could always create this independently of your usual tooling and use
> it as a base like something that someone else had created? I don't know
> StGit but I have similar stuff with my own tooling sometimes.
I've updated nfsd-next so it is based on a merge of the three
prerequisite vfs/ topic branches plus v7.1-rc5 using the mechanism you
suggested. Please give it a try.
--
Chuck Lever
^ 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 --
2024-02-07 0:41 linux-next: manual merge of the vfs-brauner tree with the nfsd tree Stephen Rothwell
2024-02-07 14:40 ` Chuck Lever
2024-02-07 14:58 ` Jeff Layton
-- 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
2025-11-16 20:34 Stephen Rothwell
2025-12-02 23:11 ` Stephen Rothwell
2024-10-23 21:15 Stephen Rothwell
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