From: Christian Brauner <brauner@kernel.org>
To: Chuck Lever <cel@kernel.org>
Cc: viro@zeniv.linux.org.uk, jack@suse.cz, hughd@google.com,
akpm@linux-foundation.org, Liam.Howlett@oracle.com,
oliver.sang@intel.com, feng.tang@intel.com,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
maple-tree@lists.infradead.org, linux-mm@kvack.org,
lkp@intel.com
Subject: Re: [PATCH v2 1/6] libfs: Re-arrange locking in offset_iterate_dir()
Date: Tue, 20 Feb 2024 10:56:53 +0100 [thread overview]
Message-ID: <20240220-ortsrand-initialen-43550ee746ed@brauner> (raw)
In-Reply-To: <170820142021.6328.15047865406275957018.stgit@91.116.238.104.host.secureserver.net>
On Sat, Feb 17, 2024 at 03:23:40PM -0500, Chuck Lever wrote:
> From: Chuck Lever <chuck.lever@oracle.com>
>
> Liam and Matthew say that once the RCU read lock is released,
> xa_state is not safe to re-use for the next xas_find() call. But the
> RCU read lock must be released on each loop iteration so that
> dput(), which might_sleep(), can be called safely.
Fwiw, functions like this:
static struct dentry *offset_find_next(struct xa_state *xas)
{
struct dentry *child, *found = NULL;
rcu_read_lock();
child = xas_next_entry(xas, U32_MAX);
if (!child)
goto out;
spin_lock(&child->d_lock);
if (simple_positive(child))
found = dget_dlock(child);
spin_unlock(&child->d_lock);
out:
rcu_read_unlock();
return found;
}
should use the new guard feature going forward imho. IOW, in the future such
helpers should be written as:
static struct dentry *offset_find_next(struct xa_state *xas)
{
struct dentry *child, *found = NULL;
guard(rcu)();
child = xas_next_entry(xas, U32_MAX);
if (!child)
return NULL;
spin_lock(&child->d_lock);
if (simple_positive(child))
found = dget_dlock(child);
spin_unlock(&child->d_lock);
return found;
}
which allows you to eliminate the goto and to have the guarantee that the rcu
lock is released when you return. This also works for other locks btw.
next prev parent reply other threads:[~2024-02-20 9:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-17 20:23 [PATCH v2 0/6] Use Maple Trees for simple_offset utilities Chuck Lever
2024-02-17 20:23 ` [PATCH v2 1/6] libfs: Re-arrange locking in offset_iterate_dir() Chuck Lever
2024-02-20 9:56 ` Christian Brauner [this message]
2024-02-21 13:15 ` Jan Kara
2024-02-17 20:23 ` [PATCH v2 2/6] libfs: Define a minimum directory offset Chuck Lever
2024-02-17 20:23 ` [PATCH v2 3/6] libfs: Add simple_offset_empty() Chuck Lever
2024-02-17 20:24 ` [PATCH v2 4/6] maple_tree: Add mtree_alloc_cyclic() Chuck Lever
2024-02-17 20:24 ` [PATCH v2 5/6] test_maple_tree: testing the cyclic allocation Chuck Lever
2024-02-17 20:24 ` [PATCH v2 6/6] libfs: Convert simple directory offsets to use a Maple Tree Chuck Lever
2024-02-21 13:31 ` Jan Kara
2024-02-21 8:41 ` [PATCH v2 0/6] Use Maple Trees for simple_offset utilities Christian Brauner
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=20240220-ortsrand-initialen-43550ee746ed@brauner \
--to=brauner@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=cel@kernel.org \
--cc=feng.tang@intel.com \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=maple-tree@lists.infradead.org \
--cc=oliver.sang@intel.com \
--cc=viro@zeniv.linux.org.uk \
/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).