>
>
> 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/