On 05/12, Davidlohr Bueso wrote:
>
> Right, but setting the flag is an indication that the tasklist_lock
> will be taken
Yes,
> and removed from the list,
Well no. If this task is not a group leader, or if it is traced this won't
happen "soon", this will happen when parent or debugger call wait(
On Tue, 12 May 2020, Oleg Nesterov wrote:
On 05/12, Davidlohr Bueso wrote:
On Tue, 12 May 2020, Oleg Nesterov wrote:
>do_each_pid_task(PIDTYPE_PGID) can race with change_pid(PIDTYPE_PGID)
>which moves the task from one hlist to another. Yes, it is safe in
>that task_struct can't go away. But
On 05/12, Davidlohr Bueso wrote:
>
> On Tue, 12 May 2020, Oleg Nesterov wrote:
>
> >do_each_pid_task(PIDTYPE_PGID) can race with change_pid(PIDTYPE_PGID)
> >which moves the task from one hlist to another. Yes, it is safe in
> >that task_struct can't go away. But still this is not right because
> >d
On Tue, 12 May 2020, Oleg Nesterov wrote:
On 05/11, Davidlohr Bueso wrote:
Currently the tasklist_lock is shared mainly in order to observe
the list atomically for the PRIO_PGRP and PRIO_USER cases, as
the actual lookups are already rcu-safe,
not really...
do_each_pid_task(PIDTYPE_PGID) can
On 05/11, Davidlohr Bueso wrote:
>
> Currently the tasklist_lock is shared mainly in order to observe
> the list atomically for the PRIO_PGRP and PRIO_USER cases, as
> the actual lookups are already rcu-safe,
not really...
do_each_pid_task(PIDTYPE_PGID) can race with change_pid(PIDTYPE_PGID)
whic
Currently the tasklist_lock is shared mainly in order to observe
the list atomically for the PRIO_PGRP and PRIO_USER cases, as
the actual lookups are already rcu-safe, providing a stable task
pointer. By removing the lock, we can race with:
(i) fork (insertion), but this is benign as the child's n
6 matches
Mail list logo
