From: Mark Fasheh <mfasheh@suse.de>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH] revert to using ocfs2_acl_chmod to avoid inode cluster lock hang
Date: Thu, 7 Jan 2016 14:55:07 -0800 [thread overview]
Message-ID: <20160107225507.GB819@wotan.suse.de> (raw)
In-Reply-To: <1452047231-30569-1-git-send-email-tariq.x.saeed@oracle.com>
On Tue, Jan 05, 2016 at 06:27:11PM -0800, Tariq Saeed wrote:
> Orabug: 21793017
>
> commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
> introduced this issue. ocfs2_setattr called by chmod command
> holds cluster wide inode lock (Orabug 21685187) when calling
> posix_acl_chmod. This latter function in turn calls ocfs2_iop_get_acl
> and ocfs2_iop_set_acl. These two are also called directly from vfs
> layer for getfacl/setfacl commands and therefore acquire the cluster wide
> inode lock. If a remote conversion request comes after the first inode
> lock in ocfs2_setattr, OCFS2_LOCK_BLOCKED will be set in l_flags. This
> will cause the second call to inode lock from the ocfs2_iop_get_acl()
> to block indefinetly.
>
> To solve this, we need to use nolock version of getacl. Since
> nolock version of posix_acl_chmod does not exist, we restore a slightly
> modified version of ocfs2_acl_chmod, which was removed in
> commit 702e5bc68ad2 ("ocfs2: use generic posix ACL infrastructure")
> that uses nolock version of getacl.
This looks good, thanks Tariq.
One comment about your description - you actually used the correct version
of posix_acl_chmod() -- specifically __posix_acl_chmod().
It's not so much that there isn't a 'nolock' version of posix_acl_chmod().
It's more that we were using the higher level version which makes calls back
into the fs. For most filesystems this is ok, so we save a lot of code by
having the function do this. For filesystems like ocfs2 which have
additional locking or other complexity it does not work, hence we directly
call the function that does the non-vfs work (__posix_acl_chmod()) and
replicate the small checks at the top fo the vfs function.
So you could replace that last paragraph with something like this:
The deleted version of ocfs2_acl_chmod() calls __posix_acl_chmod() which
does not call back into the filesystem. Therefore, we restore
ocfs2_acl_chmod() and use that instead.
Reviewed-by: Mark Fasheh <mfasheh@suse.de>
--Mark
--
Mark Fasheh
next prev parent reply other threads:[~2016-01-07 22:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 2:27 [Ocfs2-devel] [PATCH] revert to using ocfs2_acl_chmod to avoid inode cluster lock hang Tariq Saeed
2016-01-06 4:41 ` Junxiao Bi
2016-01-07 2:51 ` Tariq Saeed
2016-01-07 22:37 ` Tariq Saeed
2016-01-08 0:13 ` Tariq Saeed
2016-01-07 22:38 ` Tariq Saeed
2016-01-07 22:55 ` Mark Fasheh [this message]
2016-01-07 23:49 ` Tariq Saeed
2016-01-08 1:45 ` Mark Fasheh
2016-01-08 22:44 ` Tariq Saeed
2016-01-11 3:17 ` Junxiao Bi
2016-01-13 2:15 ` Junxiao Bi
-- strict thread matches above, loose matches on Subject: below --
2016-01-08 1:07 Tariq Saeed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160107225507.GB819@wotan.suse.de \
--to=mfasheh@suse.de \
--cc=ocfs2-devel@oss.oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).