What happened to my /proc/curproc/file?

[Konstantin Belousov]

On Mon, Sep 03, 2012 at 09:46:17PM -0400, Sam Varshavchik wrote:
> Am I the only one who's seeing this weirdness with procfs on 
> 9.0-RELEASE-p3.  Unless I'm overlooking something stupid, a process that 
> rmdir(2)s a  subdirectory of its current directory ends up with a broken  
> /proc/curproc/file symlink:
> 
> [mrsam at freebsd ~/stasher/stasher]$ cat t.c
> #include <stdio.h>
> #include <unistd.h>
> #include <sys/stat.h>
> 
> void dump(int n)
> {
> 	char buf[2048];
> 
> 	printf("Line %d, rc=%s\n", n,
> 	       (readlink("/proc/curproc/file", buf, 2048) < 0 ? "err":"ok"));
> }
> 
> int main(int argc, char **argv)
> {
> 	dump(__LINE__);
> 	mkdir("conftestdir.tst", 0777);
> 	rmdir("conftestdir.tst");
> 	dump(__LINE__);
> }
> [mrsam at freebsd ~/stasher/stasher]$ cc -o t t.c
> [mrsam at freebsd ~/stasher/stasher]$ ./t
> Line 15, rc=ok
> Line 18, rc=err
> 
> ???????
> 
The procfs links, as well as any other user of vn_fullpath(9) function,
can only translate a vnode to path if namecache contains useful data.
As such, the facilities are not guaranteed to success all the time.

In case of rmdir(2), UFS explicitely purges the cache for directory which
contained direntry of the removed directory. I suspect that you have
your test program binary located in the same directory which was the parent
of the removed one.

Similar purge is done by UFS for directories which are the sources or
destinations of the move.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20120904/163ba6ec/attachment.pgp