> Whether it works is a totally different matter. I haven't dared try this
> kernel out yet (I dislike trying out experimental new patches by rebooting
> over the net and possibly having to drive in to fix it if it breaks). It's
> entirely possible that there is something wrong with it, but I _think_ it
> should be a "small forgotten detail" problem rather than anything
> fundamental.
I took a look at the new d_move code, and it does look efficient. My
new concern though is whether there could have been references made to
the new target dentry before the switch, which will now be invalid. The
rename code is fraught with races, and it may be possible that the new
dentry is already being used.
This was a potential problem with the old code as well, but at least
there the references to the new dentry were left with the correct name,
and after the call to d_delete() unhashed the duplicate, it could serve
out its life until unused.
I think it would be safer to d_alloc a new dentry with the correct name
but no possible references, and use that with your switching code. Then
d_delete the target (as now) and dput the dentry used for the name.
Also, please consider the changes to d_alloc, d_add, and real_lookup in
my patch. These keep the dentry tree in a safe state so we don't have
to worry about the fs blocking after d_add, or corrupting the dcache by
not d_add()ing but not returning error.
Regards,
Bill