From: Zach Brown <zab@zabbo.net>
To: Valerie Aurora <val@versity.com>
Cc: rpdfs-devel@lists.linux.dev
Subject: Re: [PATCH] Add rpdfs_unlink() and rpdfs_rmdir()
Date: Tue, 3 Mar 2026 15:14:50 -0800 [thread overview]
Message-ID: <20260303231450.GA3280611@localhost.localdomain> (raw)
In-Reply-To: <20260226203858.23117-1-val@versity.com>
On Thu, Feb 26, 2026 at 09:38:58PM +0100, Valerie Aurora wrote:
> + /* prepare all the blocks for the txn */
> + do {
> + ret = rpdfs_inode_txn_prepare(rfi, &txn, dir, RBAF_WRITE) ?:
> + rpdfs_inode_txn_prepare(rfi, &txn, inode, RBAF_WRITE) ?:
> + prepare_remove_entry(rfi, &txn, dir, kd);
> + } while (rpdfs_txn_retry(rfi, &txn, &ret));
> + if (ret < 0)
> + goto out;
> +
> + /*
> + * The VFS did a bunch of checks before calling this function,
> + * but some other node could have made changes between then and
> + * now. The prepare functions only succeed if the inodes have
> + * not been freed or reused, and if the directory entry to be
> + * removed is still there. The remaining check is if the target
> + * dir of an rmdir is still empty.
> + */
> +
> + if (S_ISDIR(inode->i_mode)) {
> + if (!simple_empty(dentry)) {
> + ret = -ENOTEMPTY;
> + goto out;
> + }
simple_empty() only checks the dcache. It's for in-memory systems only.
A dir that had entries that weren't cached would pass this test. Just
check nlink.
And this is in the apply phase so it can't generate an error. It should
have been detected in prepare. Maybe a simple prepare_unlink() that
checks the prepared inodes?
- z
prev parent reply other threads:[~2026-03-03 23:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 20:38 [PATCH] Add rpdfs_unlink() and rpdfs_rmdir() Valerie Aurora
2026-03-03 23:14 ` Zach Brown [this message]
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=20260303231450.GA3280611@localhost.localdomain \
--to=zab@zabbo.net \
--cc=rpdfs-devel@lists.linux.dev \
--cc=val@versity.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.