From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [PATCH] tmpfs: Fix simple_set_acl() Date: Sun, 4 May 2014 08:42:54 -0400 Message-ID: <20140504124254.GG21635@fieldses.org> References: <20140422220815.3847.82405.stgit@klimt.1015granger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Chuck Lever Return-path: Received: from fieldses.org ([174.143.236.118]:52175 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753790AbaEDMm4 (ORCPT ); Sun, 4 May 2014 08:42:56 -0400 Content-Disposition: inline In-Reply-To: <20140422220815.3847.82405.stgit@klimt.1015granger.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: This doesn't seem upstream--whose job is it to pick this up? Maybe you could resend directly To: linus? --b. On Tue, Apr 22, 2014 at 06:08:51PM -0400, Chuck Lever wrote: > Ben Greear reports that NFSD panics in > posix_acl_equiv_mode() during an NFSv3 SETACL operation. I have > reproduced this using an exported tmpfs and cthon04 with NFSv3. > > A survey of .set_acl methods suggests that simple_set_acl() must > tolerate a NULL "acl" argument. > > Fixes: feda821e76f3bbbba4bd54d30b4d4005a7848aa5 > Signed-off-by: Chuck Lever > --- > > fs/posix_acl.c | 12 +++++++----- > 1 files changed, 7 insertions(+), 5 deletions(-) > > diff --git a/fs/posix_acl.c b/fs/posix_acl.c > index 9e363e4..0b25aae 100644 > --- a/fs/posix_acl.c > +++ b/fs/posix_acl.c > @@ -863,11 +863,13 @@ int simple_set_acl(struct inode *inode, struct posix_acl *acl, int type) > int error; > > if (type == ACL_TYPE_ACCESS) { > - error = posix_acl_equiv_mode(acl, &inode->i_mode); > - if (error < 0) > - return 0; > - if (error == 0) > - acl = NULL; > + if (acl) { > + error = posix_acl_equiv_mode(acl, &inode->i_mode); > + if (error < 0) > + return 0; > + if (error == 0) > + acl = NULL; > + } > } > > inode->i_ctime = CURRENT_TIME; > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html