[PATCH RFC 00/13] Reduction globality of tasklist_lock

[PATCH RFC 00/13] Reduction globality of tasklist_lock

[Kirill Tkhai]

tasklist_lock is used for protection of many different task links.
These are place in init_task.tasks, parent-child relationship,
ptrace waiting, place in PID lists, SID/PGID leadership, proibition
of creation of new tasks etc. It's like gone BKL, and this badly
affects on granularity of a system.

The series aims to decrease its globality and introduces a new lock
for protection of task-task relationship. The lock's name is kin_lock.
Firstly, it protects parent-child relationship. Children sibling and
real_parent fields are protected by father's kin_lock. For transfering
a child from one parent to another you should take both fathers locks.

Child's parent is protected by ptracer's kin_lock. We should take
real_parent's and ptracer's locks to attach a child to ptracer. We
should use parent's lock to notify it about exiting. tasklist_lock
is not used in exit/wait notifications since now.

Also, real_parent's kin lock protects child's threads (is the child
is multithreaded) and multithread exiting. Task's sighand is protected
by it too. After all I nested tasklist_lock under kin_lock, so the lock
order now is
		kin_lock
		tasklist_lock
		sighand->lock

But. sighand, task_struct::tasks, thread group is still safe under
tasklist_lock. We may change __exit_signal() a little bit more, but
it wants additional changing of all tasklist_lock users and makes
the series bigger (plus 8-9 patches). I don't thing it's so necessary
right now. We may do that in the future if we want. All new users
shouldn't use tasklist_lock since now if possible (but mostly current
users may be easy rewritten using RCU. In a couple of place we will
have to use tasklist_lock to stop process creation).

Besides that, tasklist_lock still protects init_task.tasks list,
PID lists, SID and PGID leadership.

The series is in RFC format, because I didn't add exhaustive comments
to the code yet. Also, nesting of rwlock_t isn't reflected in lockdep,
and arch code still uses tasklist_lock (I hadn't analyze it yet).

I'd like to hear people's opinions about that. Welcome your comments/
ideas/suggestions.

Thanks!

---

Kirill Tkhai (13):
      exit: Clarify choice of new parent in forget_original_parent()
      rwlock_t: Implement double_write_{,un}lock()
      pid_ns: Implement rwlock_t pid_ns::cr_lock for locking child_reaper
      exit: Small refactoring mm_update_next_owner()
      fs: Refactoring in get_children_pid()
      core: Add rwlock_t task_list::kin_lock
      kin_lock: Implement helpers for kin_lock locking.
      core: Use kin_lock synchronizations between parent and child and for thread group
      exit: Use for_each_thread() in do_wait()
      exit: Add struct wait_opts's member held_lock and use it for tasklist_lock
      exit: Syncronize on kin_lock while do_notify_parent()
      exit: Delete write dependence on tasklist_lock in exit_notify()
      core: Nest tasklist_lock into task_struct::kin_lock


 fs/exec.c                     |   26 ++--
 fs/proc/array.c               |   28 ++--
 include/linux/init_task.h     |    1 
 include/linux/pid_namespace.h |    1 
 include/linux/sched.h         |  303 +++++++++++++++++++++++++++++++++++++++++
 include/linux/spinlock.h      |   19 +++
 kernel/exit.c                 |  178 +++++++++++++++++-------
 kernel/fork.c                 |   13 +-
 kernel/pid.c                  |   10 +
 kernel/pid_namespace.c        |    5 -
 kernel/ptrace.c               |   53 +++++--
 kernel/signal.c               |   20 +--
 kernel/sys.c                  |   19 +--
 mm/oom_kill.c                 |    9 +
 security/keys/keyctl.c        |    4 -
 security/selinux/hooks.c      |    4 -
 16 files changed, 570 insertions(+), 123 deletions(-)

--
Signed-off-by: Kirill Tkhai <ktkhai@odin.com>

Re: [PATCH RFC 00/13] Reduction globality of tasklist_lock

[Oleg Nesterov]

On 05/25, Kirill Tkhai wrote:
>
> It's like gone BKL,

Yes...

Kirill. I just want to let you know that I am not going to ignore
this series. I'll try very much to review it this week.

But I have to admit this scares me ;) and I don't feel this all
is right. We will see.

Oleg.

Re: [PATCH RFC 00/13] Reduction globality of tasklist_lock

[Kirill Tkhai]

Hi, Oleg,

26.05.2015, 22:44, "Oleg Nesterov" <oleg@redhat.com>:
> On 05/25, Kirill Tkhai wrote:
>>  It's like gone BKL,
>
> Yes...
>
> Kirill. I just want to let you know that I am not going to ignore
> this series. I'll try very much to review it this week.
>
> But I have to admit this scares me ;) and I don't feel this all
> is right. We will see.

Nice to hear. I'll wait for your commentaries.
A couple of words how this all was tested.

The strace test was endless kernel compilation using standard or
straced gcc/make (CC="strace -o /dev/null gcc" ) and periodical
killing gcc, make or strace. No problems were observed. If there
is an idea of a test, which is mostly for threads, I'll be happy
to hear it.

Thanks!
Kirill

Re: [PATCH RFC 00/13] Reduction globality of tasklist_lock

[Kirill Tkhai]

27.05.2015, 12:30, "Kirill Tkhai" <tkhai@yandex.ru>:
> Hi, Oleg,
>
> 26.05.2015, 22:44, "Oleg Nesterov" <oleg@redhat.com>:
>>  On 05/25, Kirill Tkhai wrote:
>>>   It's like gone BKL,
>>  Yes...
>>
>>  Kirill. I just want to let you know that I am not going to ignore
>>  this series. I'll try very much to review it this week.
>>
>>  But I have to admit this scares me ;) and I don't feel this all
>>  is right. We will see.
>
> Nice to hear. I'll wait for your commentaries.
> A couple of words how this all was tested.
>
> The strace test was endless kernel compilation using standard or
> straced gcc/make (CC="strace -o /dev/null gcc" ) and periodical
> killing gcc, make or strace. No problems were observed. If there
> is an idea of a test, which is mostly for threads, I'll be happy
> to hear it.

I found some problems in the patchset and going to fix them. Please,
ignore it. I'll send new series next week.

Kirill