Oleg Nesterov <oleg@xxxxxxxxxx> writes: > On 07/29, Eric W. Biederman wrote: >> >> So I really don't think using utsname() aka current->nsproxy->uts_ns >> makes sense in nlmclnt_setlockargs. >> >> We most definitely have an inconsistency in nfs. > > I tend to agree, but can't really comment. If I could justify another couple of hours I could write the patch and justify it. I have cgroups exploding around my ears however. >> > Yes. And perhaps the patch which moves exit_task_namespaces() after >> > exit_task_work() makes sense anyway (the patch I showed). >> > >> > (but if you change nlmclnt_setlockargs() then it is not 3.11 material). >> > >> > The original motivation for 8aac62706 was the leak reported by Andrey, >> > but that leak should be also fixed by e7b2c406. "Move exit_task_namespaces() >> > from exit_notify() to do_exit()" is still fine imho, the reason for >> > exit_task_namespaces() from the middle of exit_notify() has gone away. >> > >> > But perhaps it would be better if work->func() could use ->nsproxy even >> > if the task is PF_EXITING. >> >> So far there is nothing in the nfs code that would suggest allowing >> work->func() being able to use ->nsproxy would make this code any >> better. I think that would just paper over the problem we are seeing >> right now. > > I think you misunderstood my point. > > I fully agree if you change nlmclnt_setlockargs(). I am suggesting to > move exit_task_namespaces() down after exit_task_work() as a separate > change which perhaps makes sense by itself. Not to fix this problem, > not for nfs, not for fput(). > > Just to allow work->func() to play with ->nsproxy if needed. task_work > has other users, not only fput(). So to clarify I see little evidence either way on the question of should work->funk be able to use ->nsproxy if the task is PF_EXITING. What little evidence I see suggests that we are actually better off not being able to access ->nsproxy. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
