Oleg Nesterov <[email protected]> writes: > On 04/25, Eric W. Biederman wrote: >> >> Oleg Nesterov <[email protected]> writes: >> >> > Eric, this makes me think again that we should do exit_task_namespaces() >> > after exit_task_work(). We already discussed this before, but this looks >> > like another indication this change makes sense. >> >> I know you mentioned something about that. I haven't actually had much >> time to think about it. >> >> > The problem with fput() from free_nsproxy() was hopefully also fixed by >> > e7b2c4069252. The main motivation for "move" was "outside of exit_notify". >> > Even if we fix the paths above task_work_add() can have another user which >> > wants ->nsproxy. >> > >> > What do you think? >> >> I am scratching my head. Delayed work that depends on current sort of >> blows my mind. > > But task_work_add(task) was specially introduced to run a callback in the > task's context. > >> That is utter nonsense. > > Yes I agree, _perhaps_ we can fix this particular problem without changing > the exit_namespace/work ordering, and perhaps this makes sense anyway. > > Well. I _think_ that __fput() and ima_file_free() in particular should not > depend on current and/or current->nsproxy. If nothing else, fput() can be > called by the unrelated task which looks into /proc/pid/. > > But again, task_work_add() has more and more users, and it seems that even > __fput() paths can do "everything", so perhaps it would be safer to allow > to use ->nsproxy in task_work_run.
Like I said, give me a clear motivating case. Right now not allowing nsproxy is turning up bugs in __fput. Which seems like a good thing. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
