vfs-scale, nd->inode after __do_follow_link()
Sedat Dilek
sedat.dilek at googlemail.com
Fri Jan 14 20:17:25 EST 2011
On Fri, Jan 14, 2011 at 9:40 AM, Nick Piggin <npiggin at gmail.com> wrote:
> On Fri, Jan 14, 2011 at 4:28 PM, Al Viro <viro at zeniv.linux.org.uk> wrote:
>> On Fri, Jan 14, 2011 at 03:09:10PM +1100, Nick Piggin wrote:
>>
>>> > + ? ? ? ? ? ? ? ? ? ? ? struct dentry *i = path.dentry->d_inode;
>>> > + ? ? ? ? ? ? ? ? ? ? ? if (!IS_ERR(cookie) && i->i_op->put_link)
>>> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? i->i_op->put_link(path.dentry, &nd, cookie);
>>> > ? ? ? ? ? ? ? ? ? ? ? ?/* nd.path had been dropped */
>>> > ? ? ? ? ? ? ? ? ? ? ? ?nd.path = path;
>>> > ? ? ? ? ? ? ? ? ? ? ? ?goto out_path;
>>>
>>> It should be the inode we followed, rather than the inode of the
>>> new path, I think.
>>
>> And that's what the first argument of __do_follow_link() is. I'm actually
>> tempted to rename it from path to symlink and make it const to clarify
>> the things a bit.
>
> Yes I was completely wrong there, thanks again for another good
> catch. I'll merge this in the vfs-scale branch, and ask to merge if
> there are no objections.
>
[ CCing patchwork ML ]
Can you send your patch separately, please?
Within a (long) thread it is eaten up.
As *.patch are somehow not presented as diff (see [1]), someone can't
catch them from <patchwork.k.o>.
Furthermore, it would be very cool to see linux-fsdevel (patches from
its ML) in <patchwork.d.o>.
I don't know whom to contact from the linux-fsdevel ML, sorry for this.
- Sedat -
[1] http://lkml.org/lkml/2011/1/14/55
More information about the Patchwork
mailing list