AFAICT, the only way to hit this error is to pass this function a bogus
"who" value. In that case, we probably don't want to return -1 as that
could get sent back to the client. Turn this into nfserr_serverfault,
which is a more appropriate error for a server bug like this.
Signed-off-by: Jeff Layton <[email protected]>
---
fs/nfsd/nfs4acl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfsd/nfs4acl.c b/fs/nfsd/nfs4acl.c
index d714156a19fd..b0cf00d3ee7d 100644
--- a/fs/nfsd/nfs4acl.c
+++ b/fs/nfsd/nfs4acl.c
@@ -935,5 +935,5 @@ __be32 nfs4_acl_write_who(struct xdr_stream *xdr, int who)
return 0;
}
WARN_ON_ONCE(1);
- return -1;
+ return nfserr_serverfault;
}
--
1.9.3
On Wed, 18 Jun 2014 11:42:04 -0400
"J. Bruce Fields" <[email protected]> wrote:
> On Tue, Jun 17, 2014 at 06:14:08AM -0400, Jeff Layton wrote:
> > AFAICT, the only way to hit this error is to pass this function a bogus
> > "who" value. In that case, we probably don't want to return -1 as that
> > could get sent back to the client. Turn this into nfserr_serverfault,
> > which is a more appropriate error for a server bug like this.
>
> I don't really care since there shouldn't be any way to hit this, but
> OK, applying for 3.17.
>
> --b.
>
Thanks. Yeah, it's pretty unlikely...
I saw a sparse warning from that and silencing it was the main impetus
for the patch. I guess we can also call it "future proofing". In the
event that some other bug ends causing this function to get passed a
bogus "who" arg, then I think we'll stand a better chance of noticing
it with this change.
> >
> > Signed-off-by: Jeff Layton <[email protected]>
> > ---
> > fs/nfsd/nfs4acl.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/nfsd/nfs4acl.c b/fs/nfsd/nfs4acl.c
> > index d714156a19fd..b0cf00d3ee7d 100644
> > --- a/fs/nfsd/nfs4acl.c
> > +++ b/fs/nfsd/nfs4acl.c
> > @@ -935,5 +935,5 @@ __be32 nfs4_acl_write_who(struct xdr_stream *xdr, int who)
> > return 0;
> > }
> > WARN_ON_ONCE(1);
> > - return -1;
> > + return nfserr_serverfault;
> > }
> > --
> > 1.9.3
> >
--
Jeff Layton <[email protected]>
On Tue, Jun 17, 2014 at 06:14:08AM -0400, Jeff Layton wrote:
> AFAICT, the only way to hit this error is to pass this function a bogus
> "who" value. In that case, we probably don't want to return -1 as that
> could get sent back to the client. Turn this into nfserr_serverfault,
> which is a more appropriate error for a server bug like this.
I don't really care since there shouldn't be any way to hit this, but
OK, applying for 3.17.
--b.
>
> Signed-off-by: Jeff Layton <[email protected]>
> ---
> fs/nfsd/nfs4acl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/nfsd/nfs4acl.c b/fs/nfsd/nfs4acl.c
> index d714156a19fd..b0cf00d3ee7d 100644
> --- a/fs/nfsd/nfs4acl.c
> +++ b/fs/nfsd/nfs4acl.c
> @@ -935,5 +935,5 @@ __be32 nfs4_acl_write_who(struct xdr_stream *xdr, int who)
> return 0;
> }
> WARN_ON_ONCE(1);
> - return -1;
> + return nfserr_serverfault;
> }
> --
> 1.9.3
>
On Tue, Jun 17, 2014 at 06:14:08AM -0400, Jeff Layton wrote:
> AFAICT, the only way to hit this error is to pass this function a bogus
> "who" value. In that case, we probably don't want to return -1 as that
> could get sent back to the client. Turn this into nfserr_serverfault,
> which is a more appropriate error for a server bug like this.
>
> Signed-off-by: Jeff Layton <[email protected]>
Looks good,
Reviewed-by: Christoph Hellwig <[email protected]>