All of
 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:45 UTC|newest]

Thread overview: 19+ 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-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 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-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 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.