linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: John Johansen <john@apparmor.net>
Cc: linux-fsdevel@vger.kernel.org
Subject: [RFC][BUG] ns_mkdir_op() locking is FUBAR
Date: Mon, 23 Jun 2025 22:37:47 +0100	[thread overview]
Message-ID: <20250623213747.GJ1880847@ZenIV> (raw)

	AFAICS, you are trying to put your locks outside of the
->i_rwsem *and* take them from inside your ->mkdir() instance.
This
        /* we have to unlock and then relock to get locking order right
         * for pin_fs
         */
        inode_unlock(dir);
        error = simple_pin_fs(&aafs_ops, &aafs_mnt, &aafs_count);
        mutex_lock_nested(&parent->lock, parent->level);
        inode_lock_nested(dir, I_MUTEX_PARENT);
        if (error)
                goto out;

        error = __aafs_setup_d_inode(dir, dentry, mode | S_IFDIR,  NULL,
                                     NULL, NULL, NULL);
        if (error)
                goto out_pin;

        ns = __aa_find_or_create_ns(parent, READ_ONCE(dentry->d_name.name),
                                    dentry);

is completely broken.

Think what happens if two threads call mkdir() on the same thing.
OK, the first one got through vfs_mkdir() to the point where it
calls ->mkdir().  Parent is locked (->i_rwsem, exclusive), dentry
happens to be a hashed negative (e.g. from a slightly overlapping
earlier stat(2), whatever).

Your ->mkdir() drops the lock on parent, which is the only thing
holding the second thread back.  Now, the second thread gets in
and it happens to grab parent->lock first.  It makes dentry hashed
positive, drops the lock and buggers off.  Your first thread gets
parent->lock... and calls d_instantiate() on an already positive
dentry.  At which point the data structures are FUBAR.

Better yet, have mkdir A/B race with rmdir A.  After dropping
the locks in ->mkdir() you get the second thread getting through
the entire rmdir(2).  You get to __aa_find_or_create_ns(), which
calls __aa_create_ns(), which gets to
        error = __aafs_ns_mkdir(ns, ns_subns_dir(parent), name, dir);
Unfortunately, ns_subns_dir(parent) is already NULL, so you hit
        AA_BUG(!parent);
in __aafd_ns_mkdir().

AFAICS, rmdir/rmdir races are also there and also rather unpleasant.

Could you explain what exclusion are you trying to get there?
The mechanism is currently broken, but what is it trying to achieve?

             reply	other threads:[~2025-06-23 21:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-23 21:37 Al Viro [this message]
2025-06-23 22:23 ` [RFC][BUG] ns_mkdir_op() locking is FUBAR Al Viro
2025-06-24 17:25   ` John Johansen
2025-06-23 22:28 ` Al Viro

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=20250623213747.GJ1880847@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=john@apparmor.net \
    --cc=linux-fsdevel@vger.kernel.org \
    /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).