1. 15 6月, 2013 2 次提交
    • O
      move exit_task_namespaces() outside of exit_notify() · 8aac6270
      Oleg Nesterov 提交于
      exit_notify() does exit_task_namespaces() after
      forget_original_parent(). This was needed to ensure that ->nsproxy
      can't be cleared prematurely, an exiting child we are going to
      reparent can do do_notify_parent() and use the parent's (ours) pid_ns.
      
      However, after 32084504 "pidns: use task_active_pid_ns in
      do_notify_parent" ->nsproxy != NULL is no longer needed, we rely
      on task_active_pid_ns().
      
      Move exit_task_namespaces() from exit_notify() to do_exit(), after
      exit_fs() and before exit_task_work().
      
      This solves the problem reported by Andrey, free_ipc_ns()->shm_destroy()
      does fput() which needs task_work_add().
      
      Note: this particular problem can be fixed if we change fput(), and
      that change makes sense anyway. But there is another reason to move
      the callsite. The original reason for exit_task_namespaces() from
      the middle of exit_notify() was subtle and it has already gone away,
      now this looks confusing. And this allows us do simplify exit_notify(),
      we can avoid unlock/lock(tasklist) and we can use ->exit_state instead
      of PF_EXITING in forget_original_parent().
      Reported-by: NAndrey Vagin <avagin@openvz.org>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: NAndrey Vagin <avagin@openvz.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      8aac6270
    • O
      fput: task_work_add() can fail if the caller has passed exit_task_work() · e7b2c406
      Oleg Nesterov 提交于
      fput() assumes that it can't be called after exit_task_work() but
      this is not true, for example free_ipc_ns()->shm_destroy() can do
      this. In this case fput() silently leaks the file.
      
      Change it to fallback to delayed_fput_work if task_work_add() fails.
      The patch looks complicated but it is not, it changes the code from
      
      	if (PF_KTHREAD) {
      		schedule_work(...);
      		return;
      	}
      	task_work_add(...)
      
      to
      	if (!PF_KTHREAD) {
      		if (!task_work_add(...))
      			return;
      		/* fallback */
      	}
      	schedule_work(...);
      
      As for shm_destroy() in particular, we could make another fix but I
      think this change makes sense anyway. There could be another similar
      user, it is not safe to assume that task_work_add() can't fail.
      Reported-by: NAndrey Vagin <avagin@openvz.org>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      e7b2c406
  2. 08 6月, 2013 1 次提交
  3. 05 6月, 2013 22 次提交
  4. 04 6月, 2013 2 次提交
  5. 03 6月, 2013 13 次提交