* [PATCH] nfs: explicitly reject LOCK_MAND flock() requests
@ 2012-07-23 19:46 Jeff Layton
2012-07-24 1:01 ` Jeff Layton
0 siblings, 1 reply; 2+ messages in thread
From: Jeff Layton @ 2012-07-23 19:46 UTC (permalink / raw)
To: trond.myklebust; +Cc: viro, linux-nfs
We have no mechanism to emulate LOCK_MAND locks on NFSv4, so explicitly
return -EINVAL if someone requests it.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
---
fs/nfs/file.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index 61d3670..15f4bbb 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -834,6 +834,15 @@ static int nfs_flock(struct file *filp, int cmd, struct file_lock *fl)
if (!(fl->fl_flags & FL_FLOCK))
return -ENOLCK;
+ /*
+ * The NFSv4 protocol doesn't support LOCK_MAND, which is not part of
+ * any standard. In principle we might be able to support LOCK_MAND
+ * on NFSv2/3 since NLMv3/4 support DOS share modes, but for now the
+ * NFS code is not set up for it.
+ */
+ if (fl->fl_type & LOCK_MAND)
+ return -EINVAL;
+
if (NFS_SERVER(inode)->flags & NFS_MOUNT_LOCAL_FLOCK)
is_local = 1;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] nfs: explicitly reject LOCK_MAND flock() requests
2012-07-23 19:46 [PATCH] nfs: explicitly reject LOCK_MAND flock() requests Jeff Layton
@ 2012-07-24 1:01 ` Jeff Layton
0 siblings, 0 replies; 2+ messages in thread
From: Jeff Layton @ 2012-07-24 1:01 UTC (permalink / raw)
To: Jeff Layton; +Cc: trond.myklebust, viro, linux-nfs
On Mon, 23 Jul 2012 15:46:23 -0400
Jeff Layton <jlayton@redhat.com> wrote:
> We have no mechanism to emulate LOCK_MAND locks on NFSv4, so explicitly
> return -EINVAL if someone requests it.
>
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
> ---
> fs/nfs/file.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/fs/nfs/file.c b/fs/nfs/file.c
> index 61d3670..15f4bbb 100644
> --- a/fs/nfs/file.c
> +++ b/fs/nfs/file.c
> @@ -834,6 +834,15 @@ static int nfs_flock(struct file *filp, int cmd, struct file_lock *fl)
> if (!(fl->fl_flags & FL_FLOCK))
> return -ENOLCK;
>
> + /*
> + * The NFSv4 protocol doesn't support LOCK_MAND, which is not part of
> + * any standard. In principle we might be able to support LOCK_MAND
> + * on NFSv2/3 since NLMv3/4 support DOS share modes, but for now the
> + * NFS code is not set up for it.
> + */
> + if (fl->fl_type & LOCK_MAND)
> + return -EINVAL;
> +
> if (NFS_SERVER(inode)->flags & NFS_MOUNT_LOCAL_FLOCK)
> is_local = 1;
>
Hmm...it looks like GFS2 does a similar check and returns -EOPNOTSUPP.
Should we do the same here instead of -EINVAL?
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-07-24 1:02 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-23 19:46 [PATCH] nfs: explicitly reject LOCK_MAND flock() requests Jeff Layton
2012-07-24 1:01 ` Jeff Layton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).