[PATCH 0/4] fs, tty: Make __do_SAK() less greedy in regard to tasklist_lock

[Kirill Tkhai]

Hi,

this patchset makes __do_SAK() to take tasklist_lock for very small time
in comparison to that it does now. Though this function is executed
in process context and it takes tasklist_lock read locked with interrupts enabled,
another tasks may want to take it for writing with interrupt disabled
(e.g., forking tasks), and these tasks may evoke hard lockups.

I've observed several hard lockups caused by long execution of __do_SAK()
on the node with 200 big containers. 3.10 kernel is used there, and mainline
kernel does not have differences in comparation to that, because of __do_SAK()
function has not changed for a long time. So, mainline kernel has this problem too.

The patchset proposes two optimizations in __do__SAK(). The first one is
to skip threads, when process's open files are being analyzed (see [3/4]).
We have to check thread's files only to close the race with unshare_files()
and failing exec. This can be fixed via small modifications of unshare_files().
See [1-2/4] for the details.

The second optimization is to iterate task list under rcu_read_lock().
This allows to take tasklist_lock for a very small time just to check we
reached the end of the task list. See patch [4/4] for the details.

Thanks,
Kirill

---

Kirill Tkhai (4):
      exec: Pass unshared files_struct to load_binary()
      exec: Assign unshared files after there is no way back
      tty: Iterate only thread group leaders in __do_SAK()
      tty: Use RCU read lock to iterate tasks in __do_SAK()


 drivers/tty/tty_io.c    |   34 +++++++++++++++++++++++++---------
 fs/binfmt_misc.c        |    8 ++++----
 fs/coredump.c           |    9 +++++----
 fs/exec.c               |   14 ++++++++------
 fs/file.c               |    4 +++-
 include/linux/binfmts.h |    1 +
 include/linux/fdtable.h |    4 ++--
 kernel/fork.c           |   19 +++++++------------
 8 files changed, 55 insertions(+), 38 deletions(-)

--
Signed-off-by: Kirill Tkhai <ktkhai@xxxxxxxxxxxxx>