Messages in this thread | | | Date | Thu, 24 Apr 2003 22:54:10 +0100 | From | viro@parcelfa ... | Subject | Re: rename("a","b") succeeds multiple times race |
| |
On Thu, Apr 24, 2003 at 10:34:18PM +0100, Jamie Lokier wrote: > That would be most reliable, and you want to do that in case the > filesystem is NFS, too. (On the other hand, there are filesystems > that support rename(2) but not link(2)). > > However rename(2) should not successfully rename from the _old_ path > more than once, whether the new names are all the same or not.
It shouldn't, but it's a known problem with 2.2. Unfixable without massive change of locking scheme.
What happens is that "from" lookup of second rename() succeeds before the first one is over. As the result, you get an old dentry of "a", _then_ second lookup gives you the same dentry - renamed to "b" by then. Then you get rename() done with old and new dentries being identical. Which is required to return 0 and do nothing.
It's b0rken and 2.3/2.4/2.5 prevent that crap from happening by saner locking rules (we keep the parent director{y,ies} locked across the entire "do lookups for last components and proceed with actual rename" sequence; see Documentation/filesystem/ for more details).
2.2 is hopeless in that respect - to fix that nest of races we would need to replace the locking of directories in namei.c and friends. I doubt that Alan is happy with that idea... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |