CVE-2026-93252: ocfs2: fix circular locking dependency in ocfs2_init_acl()

In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix circular locking dependency in ocfs2initacl()

A lockdep warning indicates a circular locking dependency between &oi->ipxattrsem and &journal->jtransbarrier:

WARNING: possible circular locking dependency detected is trying to acquire lock: (&oi->ipxattrsem){++++}-{4:4}, at: ocfs2initacl+0x2fd/0x7e0 fs/ocfs2/acl.c:367

but task is already holding lock: (&journal->jtransbarrier){.+.+}-{4:4}, at: ocfs2starttrans+0x3ab/0x700 fs/ocfs2/journal.c:369

The deadlock involves two code paths: Path 1 (setxattr) where ocfs2xattrset() acquires ipxattrsem (write) and then starts a transaction, which acquires jtransbarrier (read); and Path 2 (mkdir/mknod) where ocfs2mknod() starts a transaction (jtransbarrier read) and then calls ocfs2initacl(), which attempts to acquire ipxattrsem (read) on the parent directory to retrieve the default ACL.

Because rwsemaphores are subject to writer priority, a pending writer on jtransbarrier (e.g., the journal commit thread) can cause Path 1 to block, while Path 2 is blocked waiting for Path 1 to release ipxattrsem.

The patch fixes the lock ordering by precomputing the ACL state before starting the OCFS2 transaction, while preserving POSIX ACL storage semantics and the existing inode/security initialization order. By reading the parent directory's default ACL and preparing the new inode's ACLs outside the transaction, ipxattrsem is always acquired before jtransbarrier.

struct ocfs2aclstate encapsulates the prepared ACL state, while ocfs2aclinitprepare() and ocfs2aclinitrelease() avoid code duplication between ocfs2mknod() and ocfs2initsecurityandacl(). ocfs2calcxattrinit() and ocfs2initacl() use this precomputed state, removing internal ipxattrsem acquisition and redundant disk reads.

Additionally, remove the ipxattrsem acquisition from ocfs2xattrsethandle(). This function is only used while initializing a new inode that has not yet been inserted into the inode hash or attached to a dentry, meaning there is no risk of concurrent access and the lock is unnecessary.