2015-03-30 16:47:02

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH] nfsd: require an explicit option to enable pNFS

Turns out sending out layouts to any client is a bad idea if they
can't get at the storage device, so require explicit admin action
to enable pNFS.

Signed-off-by: Christoph Hellwig <[email protected]>
---
fs/nfsd/nfs4layouts.c | 2 +-
include/uapi/linux/nfsd/export.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/nfsd/nfs4layouts.c b/fs/nfsd/nfs4layouts.c
index f4e8da2..9a8254b 100644
--- a/fs/nfsd/nfs4layouts.c
+++ b/fs/nfsd/nfs4layouts.c
@@ -118,7 +118,7 @@ void nfsd4_setup_layout_type(struct svc_export *exp)
{
struct super_block *sb = exp->ex_path.mnt->mnt_sb;

- if (exp->ex_flags & NFSEXP_NOPNFS)
+ if (!(exp->ex_flags & NFSEXP_PNFS))
return;

if (sb->s_export_op->get_uuid &&
diff --git a/include/uapi/linux/nfsd/export.h b/include/uapi/linux/nfsd/export.h
index 4742f2c..d3bd6ffe 100644
--- a/include/uapi/linux/nfsd/export.h
+++ b/include/uapi/linux/nfsd/export.h
@@ -47,7 +47,7 @@
* exported filesystem.
*/
#define NFSEXP_V4ROOT 0x10000
-#define NFSEXP_NOPNFS 0x20000
+#define NFSEXP_PNFS 0x20000

/* All flags that we claim to support. (Note we don't support NOACL.) */
#define NFSEXP_ALLFLAGS 0x3FE7F
--
1.9.1



2015-03-31 13:44:56

by J. Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH] nfsd: require an explicit option to enable pNFS

On Mon, Mar 30, 2015 at 06:46:29PM +0200, Christoph Hellwig wrote:
> Turns out sending out layouts to any client is a bad idea if they
> can't get at the storage device, so require explicit admin action
> to enable pNFS.

Thanks, I'll pass along this and the accumulated fixes for 4.0 soon.

--b.

>
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
> fs/nfsd/nfs4layouts.c | 2 +-
> include/uapi/linux/nfsd/export.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfsd/nfs4layouts.c b/fs/nfsd/nfs4layouts.c
> index f4e8da2..9a8254b 100644
> --- a/fs/nfsd/nfs4layouts.c
> +++ b/fs/nfsd/nfs4layouts.c
> @@ -118,7 +118,7 @@ void nfsd4_setup_layout_type(struct svc_export *exp)
> {
> struct super_block *sb = exp->ex_path.mnt->mnt_sb;
>
> - if (exp->ex_flags & NFSEXP_NOPNFS)
> + if (!(exp->ex_flags & NFSEXP_PNFS))
> return;
>
> if (sb->s_export_op->get_uuid &&
> diff --git a/include/uapi/linux/nfsd/export.h b/include/uapi/linux/nfsd/export.h
> index 4742f2c..d3bd6ffe 100644
> --- a/include/uapi/linux/nfsd/export.h
> +++ b/include/uapi/linux/nfsd/export.h
> @@ -47,7 +47,7 @@
> * exported filesystem.
> */
> #define NFSEXP_V4ROOT 0x10000
> -#define NFSEXP_NOPNFS 0x20000
> +#define NFSEXP_PNFS 0x20000
>
> /* All flags that we claim to support. (Note we don't support NOACL.) */
> #define NFSEXP_ALLFLAGS 0x3FE7F
> --
> 1.9.1

2015-03-31 14:03:05

by Jeff Layton

[permalink] [raw]
Subject: Re: [PATCH] nfsd: require an explicit option to enable pNFS

On Mon, 30 Mar 2015 18:46:29 +0200
Christoph Hellwig <[email protected]> wrote:

> Turns out sending out layouts to any client is a bad idea if they
> can't get at the storage device, so require explicit admin action
> to enable pNFS.
>
> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
> fs/nfsd/nfs4layouts.c | 2 +-
> include/uapi/linux/nfsd/export.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfsd/nfs4layouts.c b/fs/nfsd/nfs4layouts.c
> index f4e8da2..9a8254b 100644
> --- a/fs/nfsd/nfs4layouts.c
> +++ b/fs/nfsd/nfs4layouts.c
> @@ -118,7 +118,7 @@ void nfsd4_setup_layout_type(struct svc_export *exp)
> {
> struct super_block *sb = exp->ex_path.mnt->mnt_sb;
>
> - if (exp->ex_flags & NFSEXP_NOPNFS)
> + if (!(exp->ex_flags & NFSEXP_PNFS))
> return;
>
> if (sb->s_export_op->get_uuid &&
> diff --git a/include/uapi/linux/nfsd/export.h b/include/uapi/linux/nfsd/export.h
> index 4742f2c..d3bd6ffe 100644
> --- a/include/uapi/linux/nfsd/export.h
> +++ b/include/uapi/linux/nfsd/export.h
> @@ -47,7 +47,7 @@
> * exported filesystem.
> */
> #define NFSEXP_V4ROOT 0x10000
> -#define NFSEXP_NOPNFS 0x20000
> +#define NFSEXP_PNFS 0x20000
>
> /* All flags that we claim to support. (Note we don't support NOACL.) */
> #define NFSEXP_ALLFLAGS 0x3FE7F

Don't you also need to update the expflags array in fs/nfsd/export.c?
You won't see this flag reported in nfsd.export otherwise. Not sure how
big a problem that is however...

--
Jeff Layton <[email protected]>

2015-03-31 20:25:29

by J. Bruce Fields

[permalink] [raw]
Subject: Re: [PATCH] nfsd: require an explicit option to enable pNFS

On Tue, Mar 31, 2015 at 10:02:51AM -0400, Jeff Layton wrote:
> On Mon, 30 Mar 2015 18:46:29 +0200
> Christoph Hellwig <[email protected]> wrote:
>
> > Turns out sending out layouts to any client is a bad idea if they
> > can't get at the storage device, so require explicit admin action
> > to enable pNFS.
> >
> > Signed-off-by: Christoph Hellwig <[email protected]>
> > ---
> > fs/nfsd/nfs4layouts.c | 2 +-
> > include/uapi/linux/nfsd/export.h | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/nfsd/nfs4layouts.c b/fs/nfsd/nfs4layouts.c
> > index f4e8da2..9a8254b 100644
> > --- a/fs/nfsd/nfs4layouts.c
> > +++ b/fs/nfsd/nfs4layouts.c
> > @@ -118,7 +118,7 @@ void nfsd4_setup_layout_type(struct svc_export *exp)
> > {
> > struct super_block *sb = exp->ex_path.mnt->mnt_sb;
> >
> > - if (exp->ex_flags & NFSEXP_NOPNFS)
> > + if (!(exp->ex_flags & NFSEXP_PNFS))
> > return;
> >
> > if (sb->s_export_op->get_uuid &&
> > diff --git a/include/uapi/linux/nfsd/export.h b/include/uapi/linux/nfsd/export.h
> > index 4742f2c..d3bd6ffe 100644
> > --- a/include/uapi/linux/nfsd/export.h
> > +++ b/include/uapi/linux/nfsd/export.h
> > @@ -47,7 +47,7 @@
> > * exported filesystem.
> > */
> > #define NFSEXP_V4ROOT 0x10000
> > -#define NFSEXP_NOPNFS 0x20000
> > +#define NFSEXP_PNFS 0x20000
> >
> > /* All flags that we claim to support. (Note we don't support NOACL.) */
> > #define NFSEXP_ALLFLAGS 0x3FE7F
>
> Don't you also need to update the expflags array in fs/nfsd/export.c?
> You won't see this flag reported in nfsd.export otherwise. Not sure how
> big a problem that is however...

Yeah, that should be fixed, but in a followup patch, I'm passing this
along now.

--b.