Re: processes hung after sys_renameat, and 'missing' processes

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, Jun 07, 2012 at 10:25:46PM -0700, Eric W. Biederman wrote:

> I am still learly of d_materialise_unique as it allows to create alias's
> on non-directories.  It isn't a functional problem as d_revalidate will
> catch the issue and make it look like we have a unlink/link pair instead
> of a proper rename.  However since it is possible I would like to aim
> for the higher quality of implemntation and use show renames as renames.

???

Please, explain.  link/unlink pair in which sense?  If you are thinking
of inotify and its ilk and tie some of that to dentry eviction, you
have far worse problem.  What stream of events do you expect if you
do
	some action that triggers sysfs_rename()
	stat(2) on old pathname
	stat(2) on new pathname
No matter what we do in lookup at the new pathname, the second step will
be "failed revalidate".  If you tie something (presumably unlink side of
your link/unlink pair) to that event, you'll get a very lousy series of
events, no matter what you do on the third step.

I don't see what kind of *notify hookup do you have in mind.  Anything that
treats "dentry failed revalidation or got evicted by memory pressure" as
"unlink" is completely nuts, IMO.