diff mbox

[v2,3/3] NFSv4: Fail the truncate() if the lock/open stateid is invalid

Message ID 1393959943-9919-4-git-send-email-trond.myklebust@primarydata.com (mailing list archive)
State New, archived
Headers show

Commit Message

Trond Myklebust March 4, 2014, 7:05 p.m. UTC
If the open stateid could not be recovered, or the file locks were lost,
then we should fail the truncate() operation altogether.

Reported-by: Andy Adamson <andros@netapp.com>
Link: http://lkml.kernel.org/r/1393954269-3974-1-git-send-email-andros@netapp.com
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
---
 fs/nfs/nfs4proc.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

Comments

William A. (Andy) Adamson March 5, 2014, 11:40 a.m. UTC | #1
On Tue, Mar 4, 2014 at 2:05 PM, Trond Myklebust
<trond.myklebust@primarydata.com> wrote:
> If the open stateid could not be recovered, or the file locks were lost,
> then we should fail the truncate() operation altogether.
>
> Reported-by: Andy Adamson <andros@netapp.com>
> Link: http://lkml.kernel.org/r/1393954269-3974-1-git-send-email-andros@netapp.com
> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
> ---
>  fs/nfs/nfs4proc.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index 44e088dc357c..daf41182ecfb 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -2398,13 +2398,16 @@ static int _nfs4_do_setattr(struct inode *inode, struct rpc_cred *cred,
>
>         if (nfs4_copy_delegation_stateid(&arg.stateid, inode, fmode)) {
>                 /* Use that stateid */
> -       } else if (truncate && state != NULL && nfs4_valid_open_stateid(state)) {
> +       } else if (truncate && state != NULL) {
>                 struct nfs_lockowner lockowner = {
>                         .l_owner = current->files,
>                         .l_pid = current->tgid,
>                 };
> -               nfs4_select_rw_stateid(&arg.stateid, state, FMODE_WRITE,
> -                               &lockowner);
> +               if (!nfs4_valid_open_stateid(state))
> +                       return -EBADF;
> +               if (nfs4_select_rw_stateid(&arg.stateid, state, FMODE_WRITE,
> +                               &lockowner) < 0)

AFICS this means -EIO = lost lock. Why fail the setattr? the file
handle is not bad.  Why not send a ZERO_STATEID?  At any rate, -EBADF
looks wrong to me.

-->Andy

> +                       return -EBADF;
>         } else
>                 nfs4_stateid_copy(&arg.stateid, &zero_stateid);
>
> --
> 1.8.5.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Trond Myklebust March 5, 2014, 1:29 p.m. UTC | #2
On Mar 5, 2014, at 6:40, Andy Adamson <androsadamson@gmail.com> wrote:

> On Tue, Mar 4, 2014 at 2:05 PM, Trond Myklebust
> <trond.myklebust@primarydata.com> wrote:
>> If the open stateid could not be recovered, or the file locks were lost,
>> then we should fail the truncate() operation altogether.
>> 
>> Reported-by: Andy Adamson <andros@netapp.com>
>> Link: http://lkml.kernel.org/r/1393954269-3974-1-git-send-email-andros@netapp.com
>> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
>> ---
>> fs/nfs/nfs4proc.c | 9 ++++++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>> 
>> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
>> index 44e088dc357c..daf41182ecfb 100644
>> --- a/fs/nfs/nfs4proc.c
>> +++ b/fs/nfs/nfs4proc.c
>> @@ -2398,13 +2398,16 @@ static int _nfs4_do_setattr(struct inode *inode, struct rpc_cred *cred,
>> 
>>        if (nfs4_copy_delegation_stateid(&arg.stateid, inode, fmode)) {
>>                /* Use that stateid */
>> -       } else if (truncate && state != NULL && nfs4_valid_open_stateid(state)) {
>> +       } else if (truncate && state != NULL) {
>>                struct nfs_lockowner lockowner = {
>>                        .l_owner = current->files,
>>                        .l_pid = current->tgid,
>>                };
>> -               nfs4_select_rw_stateid(&arg.stateid, state, FMODE_WRITE,
>> -                               &lockowner);
>> +               if (!nfs4_valid_open_stateid(state))
>> +                       return -EBADF;
>> +               if (nfs4_select_rw_stateid(&arg.stateid, state, FMODE_WRITE,
>> +                               &lockowner) < 0)
> 
> AFICS this means -EIO = lost lock. Why fail the setattr? the file
> handle is not bad.  Why not send a ZERO_STATEID?  At any rate, -EBADF
> looks wrong to me.

What should we use instead of EBADF? EIO doesn’t really help you figure out what is wrong or how to fix it.
diff mbox

Patch

diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 44e088dc357c..daf41182ecfb 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -2398,13 +2398,16 @@  static int _nfs4_do_setattr(struct inode *inode, struct rpc_cred *cred,
 
 	if (nfs4_copy_delegation_stateid(&arg.stateid, inode, fmode)) {
 		/* Use that stateid */
-	} else if (truncate && state != NULL && nfs4_valid_open_stateid(state)) {
+	} else if (truncate && state != NULL) {
 		struct nfs_lockowner lockowner = {
 			.l_owner = current->files,
 			.l_pid = current->tgid,
 		};
-		nfs4_select_rw_stateid(&arg.stateid, state, FMODE_WRITE,
-				&lockowner);
+		if (!nfs4_valid_open_stateid(state))
+			return -EBADF;
+		if (nfs4_select_rw_stateid(&arg.stateid, state, FMODE_WRITE,
+				&lockowner) < 0)
+			return -EBADF;
 	} else
 		nfs4_stateid_copy(&arg.stateid, &zero_stateid);