On Sun, Aug 24, 2008 at 12:03:26PM +0100, Al Viro wrote: > On Sun, Aug 24, 2008 at 11:10:14AM +0100, Al Viro wrote: > > > I agree that such transition plan makes sense, but that'll take more > > preliminary work than in your patch; there are other vfs_readdir() and > > ->readdir() callers, not just the obvious syscall ones. > > BTW, nfsd4_list_rec_dir() is FUBAR. Its users, actually - they try to use it > for lovely things like kernel-side rm -rf /var/lib/nfs/v4recovery/* and > screw up in rather amusing ways.. I'm not even talking about the effects > of OOM (dentry leak); if you rename something away from that directory, > you'll get vfs_rmdir(dir, dentry) with dentry not being a child of dir, > which means deadlock if you are lucky and underlying fs corruption if you > are not... > > I really wonder WTF is that doing in the kernel, anyway. Looks like an > obvious candidate for userland helper... Yes. Christoph complained about this before (err, 3 years ago!), though without (as far as I can tell) catching those particular bugs: http://marc.info/?l=linux-fsdevel&m=112703894118581&w=2 We eventually agreed that it was a problem and worked on a userspace replacement, but it never got to the point where I was happy enough with it to commit to the new user interface, and the effort died. I'll take a look at what we last had. --b. -- 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
