When remounting an NFS or NFS4 filesystem, the new NFS options are not
respected, yet the remount will still return success. This patch adds
a remount_fs sb op for NFS that checks any new nfs mount options against
the existing ones and fails the mount if any have changed.
This is only implemented for string-based mount options since doing
this with binary options isn't really feasible.
Signed-off-by: Jeff Layton <[email protected]>
---
fs/nfs/super.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index f4ee9d9..b49f90f 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -207,6 +207,7 @@ static int nfs_xdev_get_sb(struct file_system_type *fs_type,
int flags, const char *dev_name, void *raw_data, struct vfsmount *mnt);
static void nfs_kill_super(struct super_block *);
static void nfs_put_super(struct super_block *);
+static int nfs_remount(struct super_block *sb, int *flags, char *raw_data);
static struct file_system_type nfs_fs_type = {
.owner = THIS_MODULE,
@@ -234,6 +235,7 @@ static const struct super_operations nfs_sops = {
.umount_begin = nfs_umount_begin,
.show_options = nfs_show_options,
.show_stats = nfs_show_stats,
+ .remount_fs = nfs_remount,
};
#ifdef CONFIG_NFS_V4
@@ -278,6 +280,7 @@ static const struct super_operations nfs4_sops = {
.umount_begin = nfs_umount_begin,
.show_options = nfs_show_options,
.show_stats = nfs_show_stats,
+ .remount_fs = nfs_remount,
};
#endif
@@ -1327,6 +1330,73 @@ out_invalid_fh:
return -EINVAL;
}
+static int
+nfs_compare_remount_data(struct nfs_server *nfss,
+ struct nfs_parsed_mount_data *data)
+{
+ if (data->flags != nfss->flags ||
+ data->rsize != nfss->rsize ||
+ data->wsize != nfss->wsize ||
+ data->retrans != nfss->client->cl_timeout->to_retries ||
+ data->auth_flavors[0] != nfss->client->cl_auth->au_flavor ||
+ data->acregmin != nfss->acregmin / HZ ||
+ data->acregmax != nfss->acregmax / HZ ||
+ data->acdirmin != nfss->acdirmin / HZ ||
+ data->acdirmax != nfss->acdirmax / HZ ||
+ data->timeo != (10U * nfss->client->cl_timeout->to_initval / HZ))
+ return -EINVAL;
+ else
+ return 0;
+}
+
+static int
+nfs_remount(struct super_block *sb, int *flags, char *raw_data)
+{
+ int error;
+ struct nfs_server *nfss = sb->s_fs_info;
+ struct nfs_parsed_mount_data *data;
+ struct nfs_mount_data *options = (struct nfs_mount_data *)raw_data;
+ struct nfs4_mount_data *options4 = (struct nfs4_mount_data *)raw_data;
+
+ /*
+ * Userspace mount programs that send binary options generally send
+ * them populated with default values. We have no way to know which
+ * ones were explicitly specified. Fall back to legacy behavior and
+ * just return success.
+ */
+ if ((sb->s_type == &nfs4_fs_type && options4->version == 1) ||
+ (sb->s_type == &nfs_fs_type && options->version >= 1 &&
+ options->version <= 6))
+ return 0;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (data == NULL)
+ return -ENOMEM;
+
+ /* fill out struct with values from existing mount */
+ data->flags = nfss->flags;
+ data->rsize = nfss->rsize;
+ data->wsize = nfss->wsize;
+ data->retrans = nfss->client->cl_timeout->to_retries;
+ data->auth_flavors[0] = nfss->client->cl_auth->au_flavor;
+ data->acregmin = nfss->acregmin / HZ;
+ data->acregmax = nfss->acregmax / HZ;
+ data->acdirmin = nfss->acdirmin / HZ;
+ data->acdirmax = nfss->acdirmax / HZ;
+ data->timeo = 10U * nfss->client->cl_timeout->to_initval / HZ;
+
+ /* overwrite those values with any that were specified */
+ error = nfs_parse_mount_options((char *)options, data);
+ if (error < 0)
+ goto out;
+
+ /* compare new mount options with old ones */
+ error = nfs_compare_remount_data(nfss, data);
+out:
+ kfree(data);
+ return error;
+}
+
/*
* Initialise the common bits of the superblock
*/
--
1.5.3.6
On Sat, 2008-04-12 at 10:33 -0400, Jeff Layton wrote:
> When remounting an NFS or NFS4 filesystem, the new NFS options are not
> respected, yet the remount will still return success. This patch adds
> a remount_fs sb op for NFS that checks any new nfs mount options against
> the existing ones and fails the mount if any have changed.
>
> This is only implemented for string-based mount options since doing
> this with binary options isn't really feasible.
>
> Signed-off-by: Jeff Layton <[email protected]>
> ---
> fs/nfs/super.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 70 insertions(+), 0 deletions(-)
>
> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> index f4ee9d9..b49f90f 100644
> --- a/fs/nfs/super.c
> +++ b/fs/nfs/super.c
> @@ -207,6 +207,7 @@ static int nfs_xdev_get_sb(struct file_system_type *fs_type,
> int flags, const char *dev_name, void *raw_data, struct vfsmount *mnt);
> static void nfs_kill_super(struct super_block *);
> static void nfs_put_super(struct super_block *);
> +static int nfs_remount(struct super_block *sb, int *flags, char *raw_data);
>
> static struct file_system_type nfs_fs_type = {
> .owner = THIS_MODULE,
> @@ -234,6 +235,7 @@ static const struct super_operations nfs_sops = {
> .umount_begin = nfs_umount_begin,
> .show_options = nfs_show_options,
> .show_stats = nfs_show_stats,
> + .remount_fs = nfs_remount,
> };
>
> #ifdef CONFIG_NFS_V4
> @@ -278,6 +280,7 @@ static const struct super_operations nfs4_sops = {
> .umount_begin = nfs_umount_begin,
> .show_options = nfs_show_options,
> .show_stats = nfs_show_stats,
> + .remount_fs = nfs_remount,
> };
> #endif
>
> @@ -1327,6 +1330,73 @@ out_invalid_fh:
> return -EINVAL;
> }
>
> +static int
> +nfs_compare_remount_data(struct nfs_server *nfss,
> + struct nfs_parsed_mount_data *data)
> +{
> + if (data->flags != nfss->flags ||
> + data->rsize != nfss->rsize ||
> + data->wsize != nfss->wsize ||
> + data->retrans != nfss->client->cl_timeout->to_retries ||
> + data->auth_flavors[0] != nfss->client->cl_auth->au_flavor ||
> + data->acregmin != nfss->acregmin / HZ ||
> + data->acregmax != nfss->acregmax / HZ ||
> + data->acdirmin != nfss->acdirmin / HZ ||
> + data->acdirmax != nfss->acdirmax / HZ ||
> + data->timeo != (10U * nfss->client->cl_timeout->to_initval / HZ))
> + return -EINVAL;
> + else
^^^^^ redundant
> + return 0;
> +}
> +
> +static int
> +nfs_remount(struct super_block *sb, int *flags, char *raw_data)
> +{
> + int error;
> + struct nfs_server *nfss = sb->s_fs_info;
> + struct nfs_parsed_mount_data *data;
> + struct nfs_mount_data *options = (struct nfs_mount_data *)raw_data;
> + struct nfs4_mount_data *options4 = (struct nfs4_mount_data *)raw_data;
> +
> + /*
> + * Userspace mount programs that send binary options generally send
> + * them populated with default values. We have no way to know which
> + * ones were explicitly specified. Fall back to legacy behavior and
> + * just return success.
> + */
> + if ((sb->s_type == &nfs4_fs_type && options4->version == 1) ||
> + (sb->s_type == &nfs_fs_type && options->version >= 1 &&
> + options->version <= 6))
> + return 0;
> +
> + data = kzalloc(sizeof(*data), GFP_KERNEL);
> + if (data == NULL)
> + return -ENOMEM;
> +
> + /* fill out struct with values from existing mount */
> + data->flags = nfss->flags;
> + data->rsize = nfss->rsize;
> + data->wsize = nfss->wsize;
> + data->retrans = nfss->client->cl_timeout->to_retries;
> + data->auth_flavors[0] = nfss->client->cl_auth->au_flavor;
> + data->acregmin = nfss->acregmin / HZ;
> + data->acregmax = nfss->acregmax / HZ;
> + data->acdirmin = nfss->acdirmin / HZ;
> + data->acdirmax = nfss->acdirmax / HZ;
> + data->timeo = 10U * nfss->client->cl_timeout->to_initval / HZ;
> +
> + /* overwrite those values with any that were specified */
> + error = nfs_parse_mount_options((char *)options, data);
> + if (error < 0)
> + goto out;
> +
> + /* compare new mount options with old ones */
> + error = nfs_compare_remount_data(nfss, data);
It might be nice also to signal when someone tries to convert a udp
mount into a tcp mount, or change the server address...
You don't need to do that in the same patch, but it is a common mistake
that even experienced admins make.
> +out:
> + kfree(data);
> + return error;
> +}
> +
> /*
> * Initialise the common bits of the superblock
> */
On Sun, 20 Apr 2008 12:56:11 -0400
Trond Myklebust <[email protected]> wrote:
> It might be nice also to signal when someone tries to convert a udp
> mount into a tcp mount, or change the server address...
> You don't need to do that in the same patch, but it is a common mistake
> that even experienced admins make.
>
The original patch should make the mount call return -EINVAL if someone
tries to change from tcp to udp, or vice versa since that would change
the flags.
The original patch didn't catch changes to "addr=", but the one I just
sent out should do so.
Thanks,
--
Jeff Layton <[email protected]>
When we're given a remount request, we likely have some mount options
that will be changed. If the superblock is shared, however, we can't
allow those new options to be applied without affecting every mount
that's associated with this superblock. Track the number of mounts
associated with the superblock, and fail any remount attempts
that involve a shared superblock.
Signed-off-by: Jeff Layton <[email protected]>
---
fs/nfs/client.c | 1 +
fs/nfs/super.c | 15 +++++++++++++--
include/linux/nfs_fs_sb.h | 1 +
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index c5c0175..950f4d2 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -828,6 +828,7 @@ static struct nfs_server *nfs_alloc_server(void)
init_waitqueue_head(&server->active_wq);
atomic_set(&server->active, 0);
+ atomic_set(&server->mounts, 0);
server->io_stats = nfs_alloc_iostats();
if (!server->io_stats) {
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index b49f90f..f080f1e 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -592,6 +592,7 @@ static void nfs_umount_begin(struct vfsmount *vfsmnt, int flags)
struct nfs_server *server = NFS_SB(vfsmnt->mnt_sb);
struct rpc_clnt *rpc;
+ atomic_dec(&server->mounts);
if (!(flags & MNT_FORCE))
return;
/* -EIO all pending I/O */
@@ -1359,6 +1360,14 @@ nfs_remount(struct super_block *sb, int *flags, char *raw_data)
struct nfs4_mount_data *options4 = (struct nfs4_mount_data *)raw_data;
/*
+ * We're presumably remounting to change some mount options. Fail
+ * the mount if the superblock is shared, since the change would
+ * affect all the mounts sharing this superblock
+ */
+ if (atomic_read(&nfss->mounts) > 1)
+ return -EBUSY;
+
+ /*
* Userspace mount programs that send binary options generally send
* them populated with default values. We have no way to know which
* ones were explicitly specified. Fall back to legacy behavior and
@@ -1615,7 +1624,7 @@ static int nfs_get_sb(struct file_system_type *fs_type,
if (s->s_fs_info != server) {
nfs_free_server(server);
- server = NULL;
+ server = (struct nfs_server *) s->s_fs_info;
}
if (!s->s_root) {
@@ -1633,6 +1642,7 @@ static int nfs_get_sb(struct file_system_type *fs_type,
if (error)
goto error_splat_root;
+ atomic_inc(&server->mounts);
s->s_flags |= MS_ACTIVE;
mnt->mnt_sb = s;
mnt->mnt_root = mntroot;
@@ -2001,7 +2011,7 @@ static int nfs4_get_sb(struct file_system_type *fs_type,
if (s->s_fs_info != server) {
nfs_free_server(server);
- server = NULL;
+ server = (struct nfs_server *) s->s_fs_info;
}
if (!s->s_root) {
@@ -2015,6 +2025,7 @@ static int nfs4_get_sb(struct file_system_type *fs_type,
goto error_splat_super;
}
+ atomic_inc(&server->mounts);
s->s_flags |= MS_ACTIVE;
mnt->mnt_sb = s;
mnt->mnt_root = mntroot;
diff --git a/include/linux/nfs_fs_sb.h b/include/linux/nfs_fs_sb.h
index 3423c67..c98f522 100644
--- a/include/linux/nfs_fs_sb.h
+++ b/include/linux/nfs_fs_sb.h
@@ -117,6 +117,7 @@ struct nfs_server {
atomic_t active; /* Keep trace of any activity to this server */
wait_queue_head_t active_wq; /* Wait for any activity to stop */
+ atomic_t mounts; /* # of mounts sharing this sb */
};
/* Server capabilities */
--
1.5.3.6
On Sat, 12 Apr 2008 10:33:18 -0400
Jeff Layton <[email protected]> wrote:
> When we're given a remount request, we likely have some mount options
> that will be changed. If the superblock is shared, however, we can't
> allow those new options to be applied without affecting every mount
> that's associated with this superblock. Track the number of mounts
> associated with the superblock, and fail any remount attempts
> that involve a shared superblock.
>
> Signed-off-by: Jeff Layton <[email protected]>
> ---
> fs/nfs/client.c | 1 +
> fs/nfs/super.c | 15 +++++++++++++--
> include/linux/nfs_fs_sb.h | 1 +
> 3 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/client.c b/fs/nfs/client.c
> index c5c0175..950f4d2 100644
> --- a/fs/nfs/client.c
> +++ b/fs/nfs/client.c
> @@ -828,6 +828,7 @@ static struct nfs_server *nfs_alloc_server(void)
>
> init_waitqueue_head(&server->active_wq);
> atomic_set(&server->active, 0);
> + atomic_set(&server->mounts, 0);
>
> server->io_stats = nfs_alloc_iostats();
> if (!server->io_stats) {
> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> index b49f90f..f080f1e 100644
> --- a/fs/nfs/super.c
> +++ b/fs/nfs/super.c
> @@ -592,6 +592,7 @@ static void nfs_umount_begin(struct vfsmount *vfsmnt, int flags)
> struct nfs_server *server = NFS_SB(vfsmnt->mnt_sb);
> struct rpc_clnt *rpc;
>
> + atomic_dec(&server->mounts);
> if (!(flags & MNT_FORCE))
> return;
> /* -EIO all pending I/O */
> @@ -1359,6 +1360,14 @@ nfs_remount(struct super_block *sb, int *flags, char *raw_data)
> struct nfs4_mount_data *options4 = (struct nfs4_mount_data *)raw_data;
>
> /*
> + * We're presumably remounting to change some mount options. Fail
> + * the mount if the superblock is shared, since the change would
> + * affect all the mounts sharing this superblock
> + */
> + if (atomic_read(&nfss->mounts) > 1)
> + return -EBUSY;
> +
> + /*
> * Userspace mount programs that send binary options generally send
> * them populated with default values. We have no way to know which
> * ones were explicitly specified. Fall back to legacy behavior and
> @@ -1615,7 +1624,7 @@ static int nfs_get_sb(struct file_system_type *fs_type,
>
> if (s->s_fs_info != server) {
> nfs_free_server(server);
> - server = NULL;
> + server = (struct nfs_server *) s->s_fs_info;
> }
>
> if (!s->s_root) {
> @@ -1633,6 +1642,7 @@ static int nfs_get_sb(struct file_system_type *fs_type,
> if (error)
> goto error_splat_root;
>
> + atomic_inc(&server->mounts);
> s->s_flags |= MS_ACTIVE;
> mnt->mnt_sb = s;
> mnt->mnt_root = mntroot;
> @@ -2001,7 +2011,7 @@ static int nfs4_get_sb(struct file_system_type *fs_type,
>
> if (s->s_fs_info != server) {
> nfs_free_server(server);
> - server = NULL;
> + server = (struct nfs_server *) s->s_fs_info;
> }
>
> if (!s->s_root) {
> @@ -2015,6 +2025,7 @@ static int nfs4_get_sb(struct file_system_type *fs_type,
> goto error_splat_super;
> }
>
> + atomic_inc(&server->mounts);
> s->s_flags |= MS_ACTIVE;
> mnt->mnt_sb = s;
> mnt->mnt_root = mntroot;
> diff --git a/include/linux/nfs_fs_sb.h b/include/linux/nfs_fs_sb.h
> index 3423c67..c98f522 100644
> --- a/include/linux/nfs_fs_sb.h
> +++ b/include/linux/nfs_fs_sb.h
> @@ -117,6 +117,7 @@ struct nfs_server {
>
> atomic_t active; /* Keep trace of any activity to this server */
> wait_queue_head_t active_wq; /* Wait for any activity to stop */
> + atomic_t mounts; /* # of mounts sharing this sb */
> };
>
> /* Server capabilities */
Just a note that I'm not truly thrilled with this patch, but didn't see
any other way to do this. The s_count doesn't really seem to be
suitable for checking this since it can get incremented for other
reasons besides sharing superblocks.
The alternative would be to walk the list of mounts in the kernel and
count the number that use this superblock. But with different mount
namespaces I'm not sure how to do that...
If a counter does seem reasonable here, I'm not sure of atomic_t is
warranted for this.
Comments appreciated...
Thanks,
--
Jeff Layton <[email protected]>
On Sat, 2008-04-12 at 10:42 -0400, Jeff Layton wrote:
> On Sat, 12 Apr 2008 10:33:18 -0400
> Jeff Layton <[email protected]> wrote:
>
> > When we're given a remount request, we likely have some mount options
> > that will be changed. If the superblock is shared, however, we can't
> > allow those new options to be applied without affecting every mount
> > that's associated with this superblock. Track the number of mounts
> > associated with the superblock, and fail any remount attempts
> > that involve a shared superblock.
> >
> > Signed-off-by: Jeff Layton <[email protected]>
> > ---
> > fs/nfs/client.c | 1 +
> > fs/nfs/super.c | 15 +++++++++++++--
> > include/linux/nfs_fs_sb.h | 1 +
> > 3 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/nfs/client.c b/fs/nfs/client.c
> > index c5c0175..950f4d2 100644
> > --- a/fs/nfs/client.c
> > +++ b/fs/nfs/client.c
> > @@ -828,6 +828,7 @@ static struct nfs_server *nfs_alloc_server(void)
> >
> > init_waitqueue_head(&server->active_wq);
> > atomic_set(&server->active, 0);
> > + atomic_set(&server->mounts, 0);
> >
> > server->io_stats = nfs_alloc_iostats();
> > if (!server->io_stats) {
> > diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> > index b49f90f..f080f1e 100644
> > --- a/fs/nfs/super.c
> > +++ b/fs/nfs/super.c
> > @@ -592,6 +592,7 @@ static void nfs_umount_begin(struct vfsmount *vfsmnt, int flags)
> > struct nfs_server *server = NFS_SB(vfsmnt->mnt_sb);
> > struct rpc_clnt *rpc;
> >
> > + atomic_dec(&server->mounts);
This isn't going to work at all. The fact that nfs_umount_begin() was
called does not guarantee that the umount will actually happen:
AFAICS it will suffice to call umount while some other process is still
using the mountpoint in order to corrupt your counter.
Bind mounts will also defeat this counter, since 'mount --bind' doesn't
ever call down to the filesystem other than to resolve the paths.
> Just a note that I'm not truly thrilled with this patch, but didn't see
> any other way to do this. The s_count doesn't really seem to be
> suitable for checking this since it can get incremented for other
> reasons besides sharing superblocks.
>
> The alternative would be to walk the list of mounts in the kernel and
> count the number that use this superblock. But with different mount
> namespaces I'm not sure how to do that...
I'm not sure that it is possible to track down all the namespaces.
Cheers
Trond
On Sat, 12 Apr 2008 12:19:08 -0400
Trond Myklebust <[email protected]> wrote:
>
> On Sat, 2008-04-12 at 10:42 -0400, Jeff Layton wrote:
> > On Sat, 12 Apr 2008 10:33:18 -0400
> > Jeff Layton <[email protected]> wrote:
> >
> > > When we're given a remount request, we likely have some mount options
> > > that will be changed. If the superblock is shared, however, we can't
> > > allow those new options to be applied without affecting every mount
> > > that's associated with this superblock. Track the number of mounts
> > > associated with the superblock, and fail any remount attempts
> > > that involve a shared superblock.
> > >
> > > Signed-off-by: Jeff Layton <[email protected]>
> > > ---
> > > fs/nfs/client.c | 1 +
> > > fs/nfs/super.c | 15 +++++++++++++--
> > > include/linux/nfs_fs_sb.h | 1 +
> > > 3 files changed, 15 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/fs/nfs/client.c b/fs/nfs/client.c
> > > index c5c0175..950f4d2 100644
> > > --- a/fs/nfs/client.c
> > > +++ b/fs/nfs/client.c
> > > @@ -828,6 +828,7 @@ static struct nfs_server *nfs_alloc_server(void)
> > >
> > > init_waitqueue_head(&server->active_wq);
> > > atomic_set(&server->active, 0);
> > > + atomic_set(&server->mounts, 0);
> > >
> > > server->io_stats = nfs_alloc_iostats();
> > > if (!server->io_stats) {
> > > diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> > > index b49f90f..f080f1e 100644
> > > --- a/fs/nfs/super.c
> > > +++ b/fs/nfs/super.c
> > > @@ -592,6 +592,7 @@ static void nfs_umount_begin(struct vfsmount *vfsmnt, int flags)
> > > struct nfs_server *server = NFS_SB(vfsmnt->mnt_sb);
> > > struct rpc_clnt *rpc;
> > >
> > > + atomic_dec(&server->mounts);
>
> This isn't going to work at all. The fact that nfs_umount_begin() was
> called does not guarantee that the umount will actually happen:
> AFAICS it will suffice to call umount while some other process is still
> using the mountpoint in order to corrupt your counter.
>
Ok, I wasn't sure about that... We don't seem to have any other
fs-specific hooks in the umount codepath, so I guess this counter isn't
really feasible...
> Bind mounts will also defeat this counter, since 'mount --bind' doesn't
> ever call down to the filesystem other than to resolve the paths.
>
> > Just a note that I'm not truly thrilled with this patch, but didn't see
> > any other way to do this. The s_count doesn't really seem to be
> > suitable for checking this since it can get incremented for other
> > reasons besides sharing superblocks.
> >
> > The alternative would be to walk the list of mounts in the kernel and
> > count the number that use this superblock. But with different mount
> > namespaces I'm not sure how to do that...
>
> I'm not sure that it is possible to track down all the namespaces.
>
So how do we tell if a superblock is shared? Is that even possible? If
not, should we just not worry about this and hope for the best?
Thanks,
--
Jeff Layton <[email protected]>
On Sat, 2008-04-12 at 14:09 -0400, Jeff Layton wrote:
> So how do we tell if a superblock is shared? Is that even possible?
Aside from the heuristic hint that sb->s_count offers, I don't see how
we can tell.
> If not, should we just not worry about this and hope for the best?
That may be the best option. If it is important to people to be able to
change parameters on the fly without disrupting other mountpoints, then
there is always the possibility of mounting with the 'nosharecache'
option.
Cheers
Trond
On Sat, 12 Apr 2008 14:14:47 -0400
Trond Myklebust <[email protected]> wrote:
>
> On Sat, 2008-04-12 at 14:09 -0400, Jeff Layton wrote:
>
> > So how do we tell if a superblock is shared? Is that even possible?
>
> Aside from the heuristic hint that sb->s_count offers, I don't see how
> we can tell.
>
> > If not, should we just not worry about this and hope for the best?
>
> That may be the best option. If it is important to people to be able to
> change parameters on the fly without disrupting other mountpoints, then
> there is always the possibility of mounting with the 'nosharecache'
> option.
>
Ok, then I think my original patch should be sufficient as a fix
for remounts not returning error even though they don't apply the new
options.
BTW: is -EINVAL the correct error for this?
Peter is probably correct that we should also consider allowing at
least some options to be changed on remount, but I think that would be
best addressed by follow-up patches.
Thanks for the review so far...
--
Jeff Layton <[email protected]>