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@xxxxxxxxxxxxxxxxxx> 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. >
