Eric Lee / smarc-fsl-linux-kernel

03 Aug, 2016

1 commit

  • 61e96496d   task_work: use READ_ONCE/lockless_dereference, avoid pi_lock if !task_works ... Browse Code »

    Change task_work_cancel() to use lockless_dereference(), this is what
    the code really wants but we didn't have this helper when it was
    written.

    Also add the fast-path task->task_works == NULL check, in the likely
    case this task has no pending works and we can avoid
    spin_lock(task->pi_lock).

    While at it, change other users of ACCESS_ONCE() to use READ_ONCE().

    Link: http://lkml.kernel.org/r/20160610150042.GA13868@redhat.com
    Signed-off-by: Oleg Nesterov
    Cc: Andrea Parri
    Cc: Peter Zijlstra
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     

14 Jun, 2016

1 commit

  • be3e78449   locking/spinlock: Update spin_unlock_wait() users ... Browse Code »

    With the modified semantics of spin_unlock_wait() a number of
    explicit barriers can be removed. Also update the comment for the
    do_exit() usecase, as that was somewhat stale/obscure.

    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Andrew Morton
    Cc: Linus Torvalds
    Cc: Paul E. McKenney
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

06 Sep, 2015

1 commit

  • c82199061   task_work: remove fifo ordering guarantee ... Browse Code »

    In commit f341861fb0b ("task_work: add a scheduling point in
    task_work_run()") I fixed a latency problem adding a cond_resched()
    call.

    Later, commit ac3d0da8f329 added yet another loop to reverse a list,
    bringing back the latency spike :

    I've seen in some cases this loop taking 275 ms, if for example a
    process with 2,000,000 files is killed.

    We could add yet another cond_resched() in the reverse loop, or we
    can simply remove the reversal, as I do not think anything
    would depend on order of task_work_add() submitted works.

    Fixes: ac3d0da8f329 ("task_work: Make task_work_add() lockless")
    Signed-off-by: Eric Dumazet
    Reported-by: Maciej Żenczykowski
    Acked-by: Al Viro
    Signed-off-by: Linus Torvalds

    Eric Dumazet
     

12 Sep, 2013

2 commits

13 Sep, 2012

2 commits

  • 9da33de62   task_work: task_work_add() should not succeed after exit_task_work() ... Browse Code »

    ed3e694d "move exit_task_work() past exit_files() et.al" destroyed
    the add/exit synchronization we had, the caller itself should ensure
    task_work_add() can't race with the exiting task.

    However, this is not convenient/simple, and the only user which tries
    to do this is buggy (see the next patch). Unless the task is current,
    there is simply no way to do this in general.

    Change exit_task_work()->task_work_run() to use the dummy "work_exited"
    entry to let task_work_add() know it should fail.

    Signed-off-by: Oleg Nesterov
    Signed-off-by: Peter Zijlstra
    Cc: Al Viro
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/20120826191211.GA4228@redhat.com
    Signed-off-by: Ingo Molnar

    Oleg Nesterov
     
  • ac3d0da8f   task_work: Make task_work_add() lockless ... Browse Code »

    Change task_work's to use llist-like code to avoid pi_lock
    in task_work_add(), this makes it useable under rq->lock.

    task_work_cancel() and task_work_run() still use pi_lock
    to synchronize with each other.

    (This is in preparation for a deadlock fix.)

    Suggested-by: Peter Zijlstra
    Signed-off-by: Oleg Nesterov
    Signed-off-by: Peter Zijlstra
    Cc: Al Viro
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/20120826191209.GA4221@redhat.com
    Signed-off-by: Ingo Molnar

    Oleg Nesterov
     

22 Aug, 2012

1 commit

  • f341861fb   task_work: add a scheduling point in task_work_run() ... Browse Code »

    It seems commit 4a9d4b024a31 ("switch fput to task_work_add") re-
    introduced the problem addressed in 944be0b22472 ("close_files(): add
    scheduling point")

    If a server process with a lot of files (say 2 million tcp sockets) is
    killed, we can spend a lot of time in task_work_run() and trigger a soft
    lockup.

    Signed-off-by: Eric Dumazet
    Signed-off-by: Linus Torvalds

    Eric Dumazet
     

23 Jul, 2012

4 commits

24 May, 2012

1 commit

  • e73f8959a   task_work_add: generic process-context callbacks ... Browse Code »

    Provide a simple mechanism that allows running code in the (nonatomic)
    context of the arbitrary task.

    The caller does task_work_add(task, task_work) and this task executes
    task_work->func() either from do_notify_resume() or from do_exit(). The
    callback can rely on PF_EXITING to detect the latter case.

    "struct task_work" can be embedded in another struct, still it has "void
    *data" to handle the most common/simple case.

    This allows us to kill the ->replacement_session_keyring hack, and
    potentially this can have more users.

    Performance-wise, this adds 2 "unlikely(!hlist_empty())" checks into
    tracehook_notify_resume() and do_exit(). But at the same time we can
    remove the "replacement_session_keyring != NULL" checks from
    arch/*/signal.c and exit_creds().

    Note: task_work_add/task_work_run abuses ->pi_lock. This is only because
    this lock is already used by lookup_pi_state() to synchronize with
    do_exit() setting PF_EXITING. Fortunately the scope of this lock in
    task_work.c is really tiny, and the code is unlikely anyway.

    Signed-off-by: Oleg Nesterov
    Acked-by: David Howells
    Cc: Thomas Gleixner
    Cc: Richard Kuo
    Cc: Linus Torvalds
    Cc: Alexander Gordeev
    Cc: Chris Zankel
    Cc: David Smith
    Cc: "Frank Ch. Eigler"
    Cc: Geert Uytterhoeven
    Cc: Larry Woodman
    Cc: Peter Zijlstra
    Cc: Tejun Heo
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Al Viro

    Oleg Nesterov