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. > > 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(). Oleg. -- 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
