On Wed, 11 Apr 2018 12:31:47 -0700 Ashish Samant <ashish.sam...@oracle.com> wrote:
> While reflinking an inode, we create a new inode in orphan directory, then > take EX lock on it, reflink the original inode to orphan inode and release > EX lock. Once the lock is released another node could request it in EX mode > from ocfs2_recover_orphans() which causes downconvert of the lock, on this > node, to NL mode. > > Later we attempt to initialize security acl for the orphan inode and move > it to the reflink destination. However, while doing this we dont take EX > lock on the inode. This could potentially cause problems because we could > be starting transaction, accessing journal and modifying metadata of the > inode while holding NL lock and with another node holding EX lock on the > inode. Someone (eg, me) needs to decide which kernel version(s) need the patch. And all I have is "this could potentially cause problems". Can you please be more specific about the end-user impact? *Does* it cause problems? Is the problem sufficiently urgent to warrant a merge into 4.17? Into -stable kernels? Please always include all the end-user-impact info when fixing bugs. Thanks. > Fix this by taking orphan inode cluster lock in EX mode before > initializing security and moving orphan inode to reflink destination. > Use the __tracker variant while taking inode lock to avoid recursive > locking in the ocfs2_init_security_and_acl() call chain. _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
