> > > You are right - we do have races there. Always had. > > > And nfsd_permission() is the next target for continuation of ro-bind > > > series. Assuming that we don't simply make r/w export to hold will_write > > > all along, in which case all these checks around calls of vfs_...() in > > > there simply go away - that's also an arguable option. > > > > Yes. And that _still_ doesn't make the path_*() interface wrong. > > It would make it bloody useless for nfsd. With ecryptfs being a piss-poor > argument in favour of anything other than git rm, what's left? Another > stack frame in fs/namei.c syscalls? Since all the vfs_* functions will become static with path_* being the only caller, the compiler will be happy to get rid of that stack frame too. What is left is the guarantee, that the race-free r/o remounts will always work and some obscure caller didn't forget to surround it with the r/o checks. I think it's definitely worth it. Miklos -- 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
