From: Al Viro <viro@zeniv.linux.org.uk>
To: Gabriel Krisman Bertazi <krisman@suse.de>
Cc: Eugen Hristev <eugen.hristev@collabora.com>,
brauner@kernel.org, tytso@mit.edu, linux-ext4@vger.kernel.org,
jack@suse.cz, adilger.kernel@dilger.ca,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@collabora.com, shreeya.patel@collabora.com
Subject: Re: [PATCH 1/2] fs/dcache: introduce d_alloc_parallel_check_existing
Date: Thu, 22 Aug 2024 02:13:45 +0100 [thread overview]
Message-ID: <20240822011345.GS504335@ZenIV> (raw)
In-Reply-To: <87jzg9wjeo.fsf@mailhost.krisman.be>
On Wed, Aug 21, 2024 at 07:22:39PM -0400, Gabriel Krisman Bertazi wrote:
> Would it be acceptable to just change the dentry->d_name here in a new
> flavor of d_add_ci used only by these filesystems? We are inside the
> creation path, so the dentry has never been hashed. Concurrent lookups
> will be stuck in d_wait_lookup() until we are done and will never become
> invalid after the change because the lookup was already done
> case-insensitively, so they all match the same dentry, per-definition,
> and we know there is no other matching dentries in the directory. We'd
> only need to be careful not to expose partial names to concurrent
> parallel lookups.
*Ow*
->d_name stability rules are already convoluted as hell; that would make
them even more painful.
What locking are you going to use there?
next prev parent reply other threads:[~2024-08-22 1:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-05 6:26 [PATCH 0/2] fs/dcache: fix cache inconsistency on case-insensitive lookups Eugen Hristev
2024-07-05 6:26 ` [PATCH 1/2] fs/dcache: introduce d_alloc_parallel_check_existing Eugen Hristev
2024-08-20 20:16 ` Gabriel Krisman Bertazi
2024-08-21 9:10 ` Eugen Hristev
2024-08-21 23:22 ` Gabriel Krisman Bertazi
2024-08-22 1:13 ` Al Viro [this message]
2024-08-22 17:25 ` Gabriel Krisman Bertazi
2024-07-05 6:26 ` [PATCH 2/2] ext4: in lookup call d_add_ci if there is a case mismatch Eugen Hristev
2024-08-15 6:02 ` [PATCH 0/2] fs/dcache: fix cache inconsistency on case-insensitive lookups Eugen Hristev
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=20240822011345.GS504335@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=adilger.kernel@dilger.ca \
--cc=brauner@kernel.org \
--cc=eugen.hristev@collabora.com \
--cc=jack@suse.cz \
--cc=kernel@collabora.com \
--cc=krisman@suse.de \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shreeya.patel@collabora.com \
--cc=tytso@mit.edu \
/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.