linux-kernel - Re: Why does d_splice_alias need to check IS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKEZqK+x7MLBRFnez-XzTi3GPxoEr9p+1w25d3hkr5JLrWW2Lw@mail.gmail.com>
Date:   Sun, 27 May 2018 19:09:14 +0800
From:   Lei Chen <losemyheaven@...il.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Why does d_splice_alias need to check IS_ROOT?

Al Viro <viro@...iv.linux.org.uk> 于2018年5月27日周日 上午1:12写道：

> On Sun, May 27, 2018 at 12:33:40AM +0800, Lei Chen wrote:
> > Hello list,
> >
> > I'm insteresting in how hard link and denry lookup work and their
> > implementation.
> >
> > I know that this interface tries to connect an inode to a dentry, but
> > why does it need
> > to check whether the inode alias IS_ROOT if the inode represents a
directory?
> > And the code process in different way according to check result.  What
> > occasions
> > are they used for?

> If it's disconnected (and not an ancestor of the place where we want it),
> we can just move it in place, no questions asked.  If it is *NOT*
> disconnected, the only thing we can do is to detach it from where it
> is and move it over.  Which takes a lot more care wrt locking.

Thanks for your reply.

But why does it mean "disconnected" if IS_ROOT returns true??
Why not use hlist_unhashed(&entry->d_u.d_alias) or d_is_negative to
determine whether a dentry is connected to an inode??

I found that when we allocate a new dentry struct, its parent is not
always itself.