Messages in this thread | | | Date | Mon, 12 Apr 1999 00:53:23 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [RFC] change of lookup() method. |
| |
On Sun, 11 Apr 1999, Linus Torvalds wrote:
> > > On Sat, 10 Apr 1999, Alexander Viro wrote: > > > > Folks, right now we have ->lookup() returning 0 in case of success > > (in which case the argument gets hashed and becomes either positive or > > negative) or a negative integer in case of error (too long name, etc.). > > Proposed change: make it return a pointer to struct dentry. > > Yes. This was what I was going to do for 2.3.x anyway - there are > filesystems like autofs that want to switch dentries on you even in the > absense of aliases. > > I wasn't planning on doing this for 2.2.x, though. Do you have overriding > concerns?
VFAT has a nasty bug in rename() and I see no other way to fix it. Suppose we are doing rename("/mnt/LongDirName","/mnt/bar") and pwd of some process being /mnt/longdi~1. We'll either have the alias alive after the rename (hashed, under the old name, etc.) or we'll get a process with unhashed pwd. We've been through the latter variant already. Easily results in dentry leak. Former variant is outright BS - mv LongDirName foo; cd longdi~1; shouldn't succeed. Current code unhashes all aliases of source. Right thing for files, exploitable for directories. Notice that moving aliases does no good - target may have none. We could return -EBUSY if the source has busy aliases, but IMO it's extremely bogus, even for bandaid. I've done the change of ->lookup() type per se, but didn't finish VFAT part yet. I'll be done with it tomorrow. Then - testing... Cheers, Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |