Messages in this thread | | | Date | Fri, 25 Apr 2014 21:25:43 +0200 | From | Oleg Nesterov <> | Subject | Re: Kernel panic at Ubuntu: IMA + Apparmor |
| |
On 04/25, Eric W. Biederman wrote: > > Oleg Nesterov <oleg@redhat.com> 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.
Oleg.
| |