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)
{
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
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 <[email protected]>