Re: [PATCH 03/24] VFS: Introduce the structs and doc for a filesystem context [ver #7]

2018-05-01 Thread Randy Dunlap 
On 05/01/2018 07:29 AM, David Howells wrote:
> Randy Dunlap  wrote:
> 
>>> + (2) Parse the options and attach them to the context.  Options may be 
>>> passed
>>> + individually from userspace.
>>
>> Does this say that step (2) can be multiple small steps?
> 
> Perhaps "phase (2)" would be a better name than "step (2)".  During (2),
> multiple argument-supplying calls may be made.

Ack.

>> How does step (2) know when userspace has completed sending individual
>> options?
> 
> Moving to phase (3) terminates phase (2).  This is triggered by userspace
> writing "x create" or "x reconfigure" to the fd as things stand.
> 
>>> + (6) Return an error message attached to the context.
>>
>> where/how is this done?
> 
> That got taken out and made general - which Linus then objected to.  I need to
> reinsert this and make it fscontext-specific as most people would really like
> to have it, the mount process being able to produce so many weird and
> wonderful errors.
> 
>>> +When the VFS creates this, it allocates ->fs_context_size bytes (as 
>>> specified
>>> +by the file_system_type object) to hold both the fs_context struct and any
>>> +extra data required by the filesystem.  The fs_context struct is placed at 
>>> the
>>> +beginning of this space.  Any extra space beyond that is for use by the
>>> +filesystem.  The filesystem should wrap the struct in its own, e.g.:
>>
>>   in its own struct, 
>> e.g.:
> 
> How about "... The filesystem should wrap the struct in one of its own, e.g."?

OK.

>>> + (*) int security_fs_context_parse_option(struct fs_context *fc, char 
>>> *opt);   
>>> +
>>> + Called for each mount option.  The arguments are as for the
>>> + ->parse_option() method.  An active LSM may reject one with an error, 
>>> pass
>>> + one over and return 0 or consume one and return 1.  If consumed, the
>>
>> What does "pass one over" mean?
> 
> How about:
> 
>   An active LSM may return 0 to pass the option on to the filesystem, 1
>   to cause the option to be discarded or an error to cause the option to
>   be rejected.

Much better. Thanks.

-- 
~Randy

Re: [PATCH 03/24] VFS: Introduce the structs and doc for a filesystem context [ver #7]

2018-05-01 Thread Randy Dunlap 
On 05/01/2018 07:29 AM, David Howells wrote:
> Randy Dunlap  wrote:
> 
>>> + (2) Parse the options and attach them to the context.  Options may be 
>>> passed
>>> + individually from userspace.
>>
>> Does this say that step (2) can be multiple small steps?
> 
> Perhaps "phase (2)" would be a better name than "step (2)".  During (2),
> multiple argument-supplying calls may be made.

Ack.

>> How does step (2) know when userspace has completed sending individual
>> options?
> 
> Moving to phase (3) terminates phase (2).  This is triggered by userspace
> writing "x create" or "x reconfigure" to the fd as things stand.
> 
>>> + (6) Return an error message attached to the context.
>>
>> where/how is this done?
> 
> That got taken out and made general - which Linus then objected to.  I need to
> reinsert this and make it fscontext-specific as most people would really like
> to have it, the mount process being able to produce so many weird and
> wonderful errors.
> 
>>> +When the VFS creates this, it allocates ->fs_context_size bytes (as 
>>> specified
>>> +by the file_system_type object) to hold both the fs_context struct and any
>>> +extra data required by the filesystem.  The fs_context struct is placed at 
>>> the
>>> +beginning of this space.  Any extra space beyond that is for use by the
>>> +filesystem.  The filesystem should wrap the struct in its own, e.g.:
>>
>>   in its own struct, 
>> e.g.:
> 
> How about "... The filesystem should wrap the struct in one of its own, e.g."?

OK.

>>> + (*) int security_fs_context_parse_option(struct fs_context *fc, char 
>>> *opt);   
>>> +
>>> + Called for each mount option.  The arguments are as for the
>>> + ->parse_option() method.  An active LSM may reject one with an error, 
>>> pass
>>> + one over and return 0 or consume one and return 1.  If consumed, the
>>
>> What does "pass one over" mean?
> 
> How about:
> 
>   An active LSM may return 0 to pass the option on to the filesystem, 1
>   to cause the option to be discarded or an error to cause the option to
>   be rejected.

Much better. Thanks.

-- 
~Randy

Re: [PATCH 03/24] VFS: Introduce the structs and doc for a filesystem context [ver #7]

2018-05-01 Thread David Howells 
Randy Dunlap  wrote:

> > + (2) Parse the options and attach them to the context.  Options may be 
> > passed
> > + individually from userspace.
> 
> Does this say that step (2) can be multiple small steps?

Perhaps "phase (2)" would be a better name than "step (2)".  During (2),
multiple argument-supplying calls may be made.

> How does step (2) know when userspace has completed sending individual
> options?

Moving to phase (3) terminates phase (2).  This is triggered by userspace
writing "x create" or "x reconfigure" to the fd as things stand.

> > + (6) Return an error message attached to the context.
> 
> where/how is this done?

That got taken out and made general - which Linus then objected to.  I need to
reinsert this and make it fscontext-specific as most people would really like
to have it, the mount process being able to produce so many weird and
wonderful errors.

> > +When the VFS creates this, it allocates ->fs_context_size bytes (as 
> > specified
> > +by the file_system_type object) to hold both the fs_context struct and any
> > +extra data required by the filesystem.  The fs_context struct is placed at 
> > the
> > +beginning of this space.  Any extra space beyond that is for use by the
> > +filesystem.  The filesystem should wrap the struct in its own, e.g.:
> 
>   in its own struct, e.g.:

How about "... The filesystem should wrap the struct in one of its own, e.g."?

> > + (*) int security_fs_context_parse_option(struct fs_context *fc, char 
> > *opt);   
> > +
> > + Called for each mount option.  The arguments are as for the
> > + ->parse_option() method.  An active LSM may reject one with an error, 
> > pass
> > + one over and return 0 or consume one and return 1.  If consumed, the
> 
> What does "pass one over" mean?

How about:

An active LSM may return 0 to pass the option on to the filesystem, 1
to cause the option to be discarded or an error to cause the option to
be rejected.

David

Re: [PATCH 03/24] VFS: Introduce the structs and doc for a filesystem context [ver #7]

2018-05-01 Thread David Howells 
Randy Dunlap  wrote:

> > + (2) Parse the options and attach them to the context.  Options may be 
> > passed
> > + individually from userspace.
> 
> Does this say that step (2) can be multiple small steps?

Perhaps "phase (2)" would be a better name than "step (2)".  During (2),
multiple argument-supplying calls may be made.

> How does step (2) know when userspace has completed sending individual
> options?

Moving to phase (3) terminates phase (2).  This is triggered by userspace
writing "x create" or "x reconfigure" to the fd as things stand.

> > + (6) Return an error message attached to the context.
> 
> where/how is this done?

That got taken out and made general - which Linus then objected to.  I need to
reinsert this and make it fscontext-specific as most people would really like
to have it, the mount process being able to produce so many weird and
wonderful errors.

> > +When the VFS creates this, it allocates ->fs_context_size bytes (as 
> > specified
> > +by the file_system_type object) to hold both the fs_context struct and any
> > +extra data required by the filesystem.  The fs_context struct is placed at 
> > the
> > +beginning of this space.  Any extra space beyond that is for use by the
> > +filesystem.  The filesystem should wrap the struct in its own, e.g.:
> 
>   in its own struct, e.g.:

How about "... The filesystem should wrap the struct in one of its own, e.g."?

> > + (*) int security_fs_context_parse_option(struct fs_context *fc, char 
> > *opt);   
> > +
> > + Called for each mount option.  The arguments are as for the
> > + ->parse_option() method.  An active LSM may reject one with an error, 
> > pass
> > + one over and return 0 or consume one and return 1.  If consumed, the
> 
> What does "pass one over" mean?

How about:

An active LSM may return 0 to pass the option on to the filesystem, 1
to cause the option to be discarded or an error to cause the option to
be rejected.

David

Re: [PATCH 03/24] VFS: Introduce the structs and doc for a filesystem context [ver #7]

2018-04-22 Thread Randy Dunlap 
Hi David,

On 04/19/18 06:31, David Howells wrote:
> Introduce a filesystem context concept to be used during superblock
> creation for mount and superblock reconfiguration for remount.  This is
> allocated at the beginning of the mount procedure and into it is placed:
> 
>  (1) Filesystem type.
> 
>  (2) Namespaces.
> 
>  (3) Device name.
> 
>  (4) Superblock flags (MS_*).
> 
>  (5) Security details.
> 
>  (6) Filesystem-specific data, as set by the mount options.
> 
> Signed-off-by: David Howells 
> ---
> 
>  Documentation/filesystems/mounting.txt |  445 
> 
>  include/linux/fs_context.h |   76 +
>  2 files changed, 521 insertions(+)
>  create mode 100644 Documentation/filesystems/mounting.txt
>  create mode 100644 include/linux/fs_context.h

> diff --git a/Documentation/filesystems/mounting.txt 
> b/Documentation/filesystems/mounting.txt
> new file mode 100644
> index ..805135a66b64
> --- /dev/null
> +++ b/Documentation/filesystems/mounting.txt
> @@ -0,0 +1,445 @@
> +   ===
> +   FILESYSTEM MOUNTING
> +   ===
> +
> +CONTENTS
> +
> + (1) Overview.
> +
> + (2) The filesystem context.
> +
> + (3) The filesystem context operations.
> +
> + (4) Filesystem context security.
> +
> + (5) VFS filesystem context operations.
> +
> +
> +
> +OVERVIEW
> +
> +
> +The creation of new mounts is now to be done in a multistep process:
> +
> + (1) Create a filesystem context.
> +
> + (2) Parse the options and attach them to the context.  Options may be passed
> + individually from userspace.

Does this say that step (2) can be multiple small steps? How does step (2) know
when userspace has completed sending individual options?


> +
> + (3) Validate and pre-process the context.
> +
> + (4) Get or create a superblock and mountable root.
> +
> + (5) Perform the mount.
> +
> + (6) Return an error message attached to the context.

where/how is this done?

> +
> + (7) Destroy the context.
> +
> +To support this, the file_system_type struct gains two new fields:
> +
> + unsigned short fs_context_size;
> +
> +which indicates the total amount of space that should be allocated for 
> context
> +data (see the Filesystem Context section), and:
> +
> + int (*init_fs_context)(struct fs_context *fc, struct super_block 
> *src_sb);
> +
> +which is invoked to set up the filesystem-specific parts of a filesystem
> +context, including the additional space.  The src_sb parameter is used to
> +convey the superblock from which the filesystem may draw extra information
> +(such as namespaces) for submount (FS_CONTEXT_FOR_SUBMOUNT) or 
> reconfiguration
> +(FS_CONTEXT_FOR_RECONFIGURE) purposes - otherwise it will be NULL.
> +
> +Note that security initialisation is done *after* the filesystem is called so
> +that the namespaces may be adjusted first.
> +
> +And the super_operations struct gains one field:
> +
> + int (*reconfigure) (struct super_block *, struct fs_context *);
> +
> +This shadows the ->reconfigure() operation and takes a prepared filesystem
> +context instead of the mount flags and data page.  It may modify the sb_flags
> +in the context for the caller to pick up.
> +
> +[NOTE] reconfigure is intended as a replacement for remount_fs.
> +
> +
> +==
> +THE FILESYSTEM CONTEXT
> +==
> +
> +The creation and reconfiguration of a superblock is governed by a filesystem
> +context.  This is represented by the fs_context structure:
> +
> + struct fs_context {
> + const struct fs_context_operations *ops;
> + struct file_system_type *fs;
> + struct dentry   *root;
> + struct user_namespace   *user_ns;
> + struct net  *net_ns;
> + const struct cred   *cred;
> + char*device;
> + char*subtype;
> + void*security;
> + void*s_fs_info;
> + unsigned intsb_flags;
> + boolsloppy;
> + boolsilent;
> + booldegraded;
> + booldrop_sb;
> + enum fs_context_purpose purpose : 8;
> + };
> +
> +When the VFS creates this, it allocates ->fs_context_size bytes (as specified
> +by the file_system_type object) to hold both the fs_context struct and any
> +extra data required by the filesystem.  The fs_context struct is placed at 
> the
> +beginning of this space.  Any extra space beyond that is for use by the
> +filesystem.  The filesystem should wrap the struct in its own, e.g.:

  in its own struct, e.g.:

> +
> + struct nfs_fs_context {
> + struct

Re: [PATCH 03/24] VFS: Introduce the structs and doc for a filesystem context [ver #7]

2018-04-22 Thread Randy Dunlap 
Hi David,

On 04/19/18 06:31, David Howells wrote:
> Introduce a filesystem context concept to be used during superblock
> creation for mount and superblock reconfiguration for remount.  This is
> allocated at the beginning of the mount procedure and into it is placed:
> 
>  (1) Filesystem type.
> 
>  (2) Namespaces.
> 
>  (3) Device name.
> 
>  (4) Superblock flags (MS_*).
> 
>  (5) Security details.
> 
>  (6) Filesystem-specific data, as set by the mount options.
> 
> Signed-off-by: David Howells 
> ---
> 
>  Documentation/filesystems/mounting.txt |  445 
> 
>  include/linux/fs_context.h |   76 +
>  2 files changed, 521 insertions(+)
>  create mode 100644 Documentation/filesystems/mounting.txt
>  create mode 100644 include/linux/fs_context.h

> diff --git a/Documentation/filesystems/mounting.txt 
> b/Documentation/filesystems/mounting.txt
> new file mode 100644
> index ..805135a66b64
> --- /dev/null
> +++ b/Documentation/filesystems/mounting.txt
> @@ -0,0 +1,445 @@
> +   ===
> +   FILESYSTEM MOUNTING
> +   ===
> +
> +CONTENTS
> +
> + (1) Overview.
> +
> + (2) The filesystem context.
> +
> + (3) The filesystem context operations.
> +
> + (4) Filesystem context security.
> +
> + (5) VFS filesystem context operations.
> +
> +
> +
> +OVERVIEW
> +
> +
> +The creation of new mounts is now to be done in a multistep process:
> +
> + (1) Create a filesystem context.
> +
> + (2) Parse the options and attach them to the context.  Options may be passed
> + individually from userspace.

Does this say that step (2) can be multiple small steps? How does step (2) know
when userspace has completed sending individual options?


> +
> + (3) Validate and pre-process the context.
> +
> + (4) Get or create a superblock and mountable root.
> +
> + (5) Perform the mount.
> +
> + (6) Return an error message attached to the context.

where/how is this done?

> +
> + (7) Destroy the context.
> +
> +To support this, the file_system_type struct gains two new fields:
> +
> + unsigned short fs_context_size;
> +
> +which indicates the total amount of space that should be allocated for 
> context
> +data (see the Filesystem Context section), and:
> +
> + int (*init_fs_context)(struct fs_context *fc, struct super_block 
> *src_sb);
> +
> +which is invoked to set up the filesystem-specific parts of a filesystem
> +context, including the additional space.  The src_sb parameter is used to
> +convey the superblock from which the filesystem may draw extra information
> +(such as namespaces) for submount (FS_CONTEXT_FOR_SUBMOUNT) or 
> reconfiguration
> +(FS_CONTEXT_FOR_RECONFIGURE) purposes - otherwise it will be NULL.
> +
> +Note that security initialisation is done *after* the filesystem is called so
> +that the namespaces may be adjusted first.
> +
> +And the super_operations struct gains one field:
> +
> + int (*reconfigure) (struct super_block *, struct fs_context *);
> +
> +This shadows the ->reconfigure() operation and takes a prepared filesystem
> +context instead of the mount flags and data page.  It may modify the sb_flags
> +in the context for the caller to pick up.
> +
> +[NOTE] reconfigure is intended as a replacement for remount_fs.
> +
> +
> +==
> +THE FILESYSTEM CONTEXT
> +==
> +
> +The creation and reconfiguration of a superblock is governed by a filesystem
> +context.  This is represented by the fs_context structure:
> +
> + struct fs_context {
> + const struct fs_context_operations *ops;
> + struct file_system_type *fs;
> + struct dentry   *root;
> + struct user_namespace   *user_ns;
> + struct net  *net_ns;
> + const struct cred   *cred;
> + char*device;
> + char*subtype;
> + void*security;
> + void*s_fs_info;
> + unsigned intsb_flags;
> + boolsloppy;
> + boolsilent;
> + booldegraded;
> + booldrop_sb;
> + enum fs_context_purpose purpose : 8;
> + };
> +
> +When the VFS creates this, it allocates ->fs_context_size bytes (as specified
> +by the file_system_type object) to hold both the fs_context struct and any
> +extra data required by the filesystem.  The fs_context struct is placed at 
> the
> +beginning of this space.  Any extra space beyond that is for use by the
> +filesystem.  The filesystem should wrap the struct in its own, e.g.:

  in its own struct, e.g.:

> +
> + struct nfs_fs_context {
> + struct fs_context fc;
> +

[PATCH 03/24] VFS: Introduce the structs and doc for a filesystem context [ver #7]

2018-04-19 Thread David Howells 
Introduce a filesystem context concept to be used during superblock
creation for mount and superblock reconfiguration for remount.  This is
allocated at the beginning of the mount procedure and into it is placed:

 (1) Filesystem type.

 (2) Namespaces.

 (3) Device name.

 (4) Superblock flags (MS_*).

 (5) Security details.

 (6) Filesystem-specific data, as set by the mount options.

Signed-off-by: David Howells 
---

 Documentation/filesystems/mounting.txt |  445 
 include/linux/fs_context.h |   76 +
 2 files changed, 521 insertions(+)
 create mode 100644 Documentation/filesystems/mounting.txt
 create mode 100644 include/linux/fs_context.h

diff --git a/Documentation/filesystems/mounting.txt 
b/Documentation/filesystems/mounting.txt
new file mode 100644
index ..805135a66b64
--- /dev/null
+++ b/Documentation/filesystems/mounting.txt
@@ -0,0 +1,445 @@
+ ===
+ FILESYSTEM MOUNTING
+ ===
+
+CONTENTS
+
+ (1) Overview.
+
+ (2) The filesystem context.
+
+ (3) The filesystem context operations.
+
+ (4) Filesystem context security.
+
+ (5) VFS filesystem context operations.
+
+
+
+OVERVIEW
+
+
+The creation of new mounts is now to be done in a multistep process:
+
+ (1) Create a filesystem context.
+
+ (2) Parse the options and attach them to the context.  Options may be passed
+ individually from userspace.
+
+ (3) Validate and pre-process the context.
+
+ (4) Get or create a superblock and mountable root.
+
+ (5) Perform the mount.
+
+ (6) Return an error message attached to the context.
+
+ (7) Destroy the context.
+
+To support this, the file_system_type struct gains two new fields:
+
+   unsigned short fs_context_size;
+
+which indicates the total amount of space that should be allocated for context
+data (see the Filesystem Context section), and:
+
+   int (*init_fs_context)(struct fs_context *fc, struct super_block 
*src_sb);
+
+which is invoked to set up the filesystem-specific parts of a filesystem
+context, including the additional space.  The src_sb parameter is used to
+convey the superblock from which the filesystem may draw extra information
+(such as namespaces) for submount (FS_CONTEXT_FOR_SUBMOUNT) or reconfiguration
+(FS_CONTEXT_FOR_RECONFIGURE) purposes - otherwise it will be NULL.
+
+Note that security initialisation is done *after* the filesystem is called so
+that the namespaces may be adjusted first.
+
+And the super_operations struct gains one field:
+
+   int (*reconfigure) (struct super_block *, struct fs_context *);
+
+This shadows the ->reconfigure() operation and takes a prepared filesystem
+context instead of the mount flags and data page.  It may modify the sb_flags
+in the context for the caller to pick up.
+
+[NOTE] reconfigure is intended as a replacement for remount_fs.
+
+
+==
+THE FILESYSTEM CONTEXT
+==
+
+The creation and reconfiguration of a superblock is governed by a filesystem
+context.  This is represented by the fs_context structure:
+
+   struct fs_context {
+   const struct fs_context_operations *ops;
+   struct file_system_type *fs;
+   struct dentry   *root;
+   struct user_namespace   *user_ns;
+   struct net  *net_ns;
+   const struct cred   *cred;
+   char*device;
+   char*subtype;
+   void*security;
+   void*s_fs_info;
+   unsigned intsb_flags;
+   boolsloppy;
+   boolsilent;
+   booldegraded;
+   booldrop_sb;
+   enum fs_context_purpose purpose : 8;
+   };
+
+When the VFS creates this, it allocates ->fs_context_size bytes (as specified
+by the file_system_type object) to hold both the fs_context struct and any
+extra data required by the filesystem.  The fs_context struct is placed at the
+beginning of this space.  Any extra space beyond that is for use by the
+filesystem.  The filesystem should wrap the struct in its own, e.g.:
+
+   struct nfs_fs_context {
+   struct fs_context fc;
+   ...
+   };
+
+placing the fs_context struct first.  container_of() can then be used.  The
+file_system_type would be initialised thus:
+
+   struct file_system_type nfs = {
+   ...
+   .fs_context_size= sizeof(struct nfs_fs_context),
+   .init_fs_context= nfs_init_fs_context,
+   ...
+   };
+
+The fs_context fields are as follows:
+
+ (*) const struct fs_context_operations *ops
+
+ These are operations that can be

[PATCH 03/24] VFS: Introduce the structs and doc for a filesystem context [ver #7]

2018-04-19 Thread David Howells 
Introduce a filesystem context concept to be used during superblock
creation for mount and superblock reconfiguration for remount.  This is
allocated at the beginning of the mount procedure and into it is placed:

 (1) Filesystem type.

 (2) Namespaces.

 (3) Device name.

 (4) Superblock flags (MS_*).

 (5) Security details.

 (6) Filesystem-specific data, as set by the mount options.

Signed-off-by: David Howells 
---

 Documentation/filesystems/mounting.txt |  445 
 include/linux/fs_context.h |   76 +
 2 files changed, 521 insertions(+)
 create mode 100644 Documentation/filesystems/mounting.txt
 create mode 100644 include/linux/fs_context.h

diff --git a/Documentation/filesystems/mounting.txt 
b/Documentation/filesystems/mounting.txt
new file mode 100644
index ..805135a66b64
--- /dev/null
+++ b/Documentation/filesystems/mounting.txt
@@ -0,0 +1,445 @@
+ ===
+ FILESYSTEM MOUNTING
+ ===
+
+CONTENTS
+
+ (1) Overview.
+
+ (2) The filesystem context.
+
+ (3) The filesystem context operations.
+
+ (4) Filesystem context security.
+
+ (5) VFS filesystem context operations.
+
+
+
+OVERVIEW
+
+
+The creation of new mounts is now to be done in a multistep process:
+
+ (1) Create a filesystem context.
+
+ (2) Parse the options and attach them to the context.  Options may be passed
+ individually from userspace.
+
+ (3) Validate and pre-process the context.
+
+ (4) Get or create a superblock and mountable root.
+
+ (5) Perform the mount.
+
+ (6) Return an error message attached to the context.
+
+ (7) Destroy the context.
+
+To support this, the file_system_type struct gains two new fields:
+
+   unsigned short fs_context_size;
+
+which indicates the total amount of space that should be allocated for context
+data (see the Filesystem Context section), and:
+
+   int (*init_fs_context)(struct fs_context *fc, struct super_block 
*src_sb);
+
+which is invoked to set up the filesystem-specific parts of a filesystem
+context, including the additional space.  The src_sb parameter is used to
+convey the superblock from which the filesystem may draw extra information
+(such as namespaces) for submount (FS_CONTEXT_FOR_SUBMOUNT) or reconfiguration
+(FS_CONTEXT_FOR_RECONFIGURE) purposes - otherwise it will be NULL.
+
+Note that security initialisation is done *after* the filesystem is called so
+that the namespaces may be adjusted first.
+
+And the super_operations struct gains one field:
+
+   int (*reconfigure) (struct super_block *, struct fs_context *);
+
+This shadows the ->reconfigure() operation and takes a prepared filesystem
+context instead of the mount flags and data page.  It may modify the sb_flags
+in the context for the caller to pick up.
+
+[NOTE] reconfigure is intended as a replacement for remount_fs.
+
+
+==
+THE FILESYSTEM CONTEXT
+==
+
+The creation and reconfiguration of a superblock is governed by a filesystem
+context.  This is represented by the fs_context structure:
+
+   struct fs_context {
+   const struct fs_context_operations *ops;
+   struct file_system_type *fs;
+   struct dentry   *root;
+   struct user_namespace   *user_ns;
+   struct net  *net_ns;
+   const struct cred   *cred;
+   char*device;
+   char*subtype;
+   void*security;
+   void*s_fs_info;
+   unsigned intsb_flags;
+   boolsloppy;
+   boolsilent;
+   booldegraded;
+   booldrop_sb;
+   enum fs_context_purpose purpose : 8;
+   };
+
+When the VFS creates this, it allocates ->fs_context_size bytes (as specified
+by the file_system_type object) to hold both the fs_context struct and any
+extra data required by the filesystem.  The fs_context struct is placed at the
+beginning of this space.  Any extra space beyond that is for use by the
+filesystem.  The filesystem should wrap the struct in its own, e.g.:
+
+   struct nfs_fs_context {
+   struct fs_context fc;
+   ...
+   };
+
+placing the fs_context struct first.  container_of() can then be used.  The
+file_system_type would be initialised thus:
+
+   struct file_system_type nfs = {
+   ...
+   .fs_context_size= sizeof(struct nfs_fs_context),
+   .init_fs_context= nfs_init_fs_context,
+   ...
+   };
+
+The fs_context fields are as follows:
+
+ (*) const struct fs_context_operations *ops
+
+ These are operations that can be done on a filesystem