Re: [RFC] weird stuff in exfat_lookup()

[Sungjong Seo <sjdev.seo@gmail.com>]

Hello? This is Sungjong. Currently, I am unable to reply using my
samsung.com email, so I am responding with my other Gmail account.

On 2/28/25 14:44, Namjae Jeon wrote:
> On Fri, Feb 28, 2025 at 7:48 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>>
>>         There's a really odd comment in that thing:
>>                 /*
>>                  * Unhashed alias is able to exist because of revalidate()
>>                  * called by lookup_fast. You can easily make this status
>>                  * by calling create and lookup concurrently
>>                  * In such case, we reuse an alias instead of new dentry
>>                  */
>> and AFAICS it had been there since the original merge.  What I don't
>> understand is how the hell could revalidate result in that -
>> exfat_d_revalidate() always returns 1 on any positive dentry and alias is
>> obviously positive (it has the same inode as the one we are about to use).
>>
>> It mentions a way to reproduce that, but I don't understand what does
>> that refer to; could you give details?
> We need to find out the history of it.
> Sungjong, Could you please check the history of how this code came in?
I believe this code is intended to address issues that could arise from
the stacked FS nested mount structure used in older versions of Android,
which are unlikely to occur in the general Linux VFS. However, I will
need to look into the modification history to confirm this, and it might
take some time.

Additionally, there is unnecessary code remaining in `exfat_lookup`.
This is because linux-exfat is based on Samsung's fat/exfat integrated
implementation, sdfat. We need to address these legacy issues one by one.

Thank you.
> 
> Thanks.
>