linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] nfs3_list_one_acl(): check get_acl() result with IS_ERR_OR_NULL
@ 2014-07-26 11:58 Andrey Utkin
  2014-07-27 13:19 ` Christoph Hellwig
  0 siblings, 1 reply; 4+ messages in thread
From: Andrey Utkin @ 2014-07-26 11:58 UTC (permalink / raw)
  To: trond.myklebust; +Cc: linux-kernel, linux-nfs, kernel-janitors, Andrey Utkin

There was a check for result being not NULL. But get_acl() may return
NULL, or ERR_PTR, or actual pointer.
The purpose of the function where current change is done is to "list
ACLs only when they are available", so any error condition of get_acl()
mustn't be elevated, and returning 0 there is still valid.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81111
Signed-off-by: Andrey Utkin <andrey.krieger.utkin@gmail.com>
---
 fs/nfs/nfs3acl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/nfs3acl.c b/fs/nfs/nfs3acl.c
index 8f854dd..d0fec26 100644
--- a/fs/nfs/nfs3acl.c
+++ b/fs/nfs/nfs3acl.c
@@ -256,7 +256,7 @@ nfs3_list_one_acl(struct inode *inode, int type, const char *name, void *data,
 	char *p = data + *result;
 
 	acl = get_acl(inode, type);
-	if (!acl)
+	if (IS_ERR_OR_NULL(acl))
 		return 0;
 
 	posix_acl_release(acl);
-- 
2.0.0


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] nfs3_list_one_acl(): check get_acl() result with IS_ERR_OR_NULL
  2014-07-26 11:58 [PATCH] nfs3_list_one_acl(): check get_acl() result with IS_ERR_OR_NULL Andrey Utkin
@ 2014-07-27 13:19 ` Christoph Hellwig
  2014-07-27 15:13   ` Trond Myklebust
  0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2014-07-27 13:19 UTC (permalink / raw)
  To: Andrey Utkin; +Cc: trond.myklebust, linux-kernel, linux-nfs, kernel-janitors

On Sat, Jul 26, 2014 at 02:58:01PM +0300, Andrey Utkin wrote:
> There was a check for result being not NULL. But get_acl() may return
> NULL, or ERR_PTR, or actual pointer.
> The purpose of the function where current change is done is to "list
> ACLs only when they are available", so any error condition of get_acl()
> mustn't be elevated, and returning 0 there is still valid.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81111
> Signed-off-by: Andrey Utkin <andrey.krieger.utkin@gmail.com>

Looks good, thanks!

Reviewed-by: Christoph Hellwig <hch@lst.de>

should probably get a cc to stable as the original patch has one
as well.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] nfs3_list_one_acl(): check get_acl() result with IS_ERR_OR_NULL
  2014-07-27 13:19 ` Christoph Hellwig
@ 2014-07-27 15:13   ` Trond Myklebust
  2014-07-27 19:50     ` Christoph Hellwig
  0 siblings, 1 reply; 4+ messages in thread
From: Trond Myklebust @ 2014-07-27 15:13 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andrey Utkin, Linux Kernel mailing list, Linux NFS Mailing List,
	kernel-janitors, Russell King

On Sun, Jul 27, 2014 at 9:19 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Sat, Jul 26, 2014 at 02:58:01PM +0300, Andrey Utkin wrote:
>> There was a check for result being not NULL. But get_acl() may return
>> NULL, or ERR_PTR, or actual pointer.
>> The purpose of the function where current change is done is to "list
>> ACLs only when they are available", so any error condition of get_acl()
>> mustn't be elevated, and returning 0 there is still valid.
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81111
>> Signed-off-by: Andrey Utkin <andrey.krieger.utkin@gmail.com>
>
> Looks good, thanks!
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
> should probably get a cc to stable as the original patch has one
> as well.

Why are we not passing the error code back to the caller here in the
case where we have one? One of the main purposes of returning an error
in get_acl() is to ensure that we pass -EOPNOTSUPP if the operation
fails due to lack of server support.

Cheers
  Trond

-- 
Trond Myklebust

Linux NFS client maintainer, PrimaryData

trond.myklebust@primarydata.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] nfs3_list_one_acl(): check get_acl() result with IS_ERR_OR_NULL
  2014-07-27 15:13   ` Trond Myklebust
@ 2014-07-27 19:50     ` Christoph Hellwig
  0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2014-07-27 19:50 UTC (permalink / raw)
  To: Trond Myklebust
  Cc: Christoph Hellwig, Andrey Utkin, Linux Kernel mailing list,
	Linux NFS Mailing List, kernel-janitors, Russell King

On Sun, Jul 27, 2014 at 11:13:50AM -0400, Trond Myklebust wrote:
> Why are we not passing the error code back to the caller here in the
> case where we have one? One of the main purposes of returning an error
> in get_acl() is to ensure that we pass -EOPNOTSUPP if the operation
> fails due to lack of server support.

Do we really want to return EOPNOTSUPP from listxattr?  Seems like
simply not listing anything if the server doesn't support ACLs would
be the usual behaviour.  E.g. on local filesystems we'll also just get
back an empty list of xattrs if ACLs aren't supported and not other
attribute is set.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-07-27 19:50 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-07-26 11:58 [PATCH] nfs3_list_one_acl(): check get_acl() result with IS_ERR_OR_NULL Andrey Utkin
2014-07-27 13:19 ` Christoph Hellwig
2014-07-27 15:13   ` Trond Myklebust
2014-07-27 19:50     ` Christoph Hellwig

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).