archive mirror
 help / color / mirror / Atom feed
From: "André Almeida" <>
To: Al Viro <>
Cc: Hugh Dickins <>,
	Andrew Morton <>,,,,,,,
	Daniel Rosenberg <>
Subject: Re: [RFC PATCH 2/4] mm: shmem: Support case-insensitive file name lookups
Date: Wed, 24 Mar 2021 17:44:25 -0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Al Viro,

Às 20:19 de 23/03/21, Al Viro escreveu:
> On Tue, Mar 23, 2021 at 04:59:39PM -0300, André Almeida wrote:
>> * dcache handling:
>> For now, negative lookups are not inserted in the dcache, since they
>> would need to be invalidated anyway, because we can't trust missing file
>> dentries. This is bad for performance but requires some leveraging of
>> the VFS layer to fix. We can live without that for now, and so does
>> everyone else.
> "For now"?  Not a single practical suggestion has ever materialized.
> Pardon me, but by now I'm very sceptical about the odds of that
> ever changing.  And no, I don't have any suggestions either.

Right, I'll reword this to reflect that there's no expectation that this 
will be done, while keeping documented this performance issue.

>> The lookup() path at tmpfs creates negatives dentries, that are later
>> instantiated if the file is created. In that way, all files in tmpfs
>> have a dentry given that the filesystem exists exclusively in memory.
>> As explained above, we don't have negative dentries for casefold files,
>> so dentries are created at lookup() iff files aren't casefolded. Else,
>> the dentry is created just before being instantiated at create path.
>> At the remove path, dentries are invalidated for casefolded files.
> Umm...  What happens to those assertions if previously sane directory
> gets case-buggered?  You've got an ioctl for doing just that...
> Incidentally, that ioctl is obviously racy - result of that simple_empty()
> might have nothing to do with reality before it is returned to caller.
> And while we are at it, simple_empty() doesn't check a damn thing about
> negative dentries in there...

Thanks for pointing those issues. I'll move my lock at IOCTL to make 
impossible to change directory attributes and add a file there at the 
same time. About the negative dentries that existed before at that 
directory, I believe the way to solve this is by invalidating them all. 
How that sound to you?


  reply	other threads:[~2021-03-24 20:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-23 19:59 [RFC PATCH 0/4] mm: shmem: Add case-insensitive support for tmpfs André Almeida
2021-03-23 19:59 ` [RFC PATCH 1/4] Revert "libfs: unexport generic_ci_d_compare() and generic_ci_d_hash()" André Almeida
2021-03-23 20:15   ` Matthew Wilcox
2021-03-24 20:09     ` André Almeida
2021-03-23 19:59 ` [RFC PATCH 2/4] mm: shmem: Support case-insensitive file name lookups André Almeida
2021-03-23 20:18   ` Gabriel Krisman Bertazi
2021-03-24 20:17     ` André Almeida
2021-03-23 23:19   ` Al Viro
2021-03-24 20:44     ` André Almeida [this message]
2021-03-23 19:59 ` [RFC PATCH 3/4] mm: shmem: Add IOCTL support for tmpfs André Almeida
2021-03-23 22:15   ` Gabriel Krisman Bertazi
2021-03-23 19:59 ` [RFC PATCH 4/4] docs: tmpfs: Add casefold options André Almeida
2021-03-23 21:58   ` Randy Dunlap
2021-03-25 14:27     ` André Almeida
2021-03-23 22:19   ` Gabriel Krisman Bertazi
2021-03-24 20:47     ` André Almeida

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* 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).