"J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes: > On Tue, Aug 04, 2015 at 05:58:59PM -0500, Eric W. Biederman wrote: >> >> No problem. The basic question is: can 2Billion renames be performed on >> the same filesystem in less time than a single path lookup? Allowing >> the use of a 32bit counter. > > Certainly if you have control over an NFS or FUSE server then you can > arrange for that to happen--just delay the lookup until you've processed > enough renames. I don't know if that's interesting.... Not particularly when the whole point is to start with a bind mount, do something trick and then have access to the whole filesystem instead of just the part of the filesystem exposed by the bind mount. If you control the filesystem you already have access to the entire filesystem, so you don't need to do something trick. That something tricky is a well placed rename that borks the tree structure and causes .. to never see the subdirectory that is the root of the bind mount. >> If you could look up thread and tell me what you think of the issue with >> file handle to dentry conversion and bind mounts I would be appreciate. > > OK, I see your comments in "[PATCH review 0/6] Bind mount escape fixes", > I'm not sure I understand yet, I'll take a closer look. Thanks. The file handle reconstitution code can certainly be affected by all of this. Given that it is an failure if reconnect_path can't reconnect the path of a file handle. I think it can reasonably considered an error in all cases if that path is outside of an exported bind mount, but I don't know that area particularly well. The solution might just be don't export file handles from bind mounts. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
