lkml.org 
[lkml]   [2019]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[PATCH 0/4] Signal: Fix hard lockup problem in flush_sigqueue()
Date
It was found that if a process has accumulated sufficient number of
pending signals, the exiting of that process may cause its parent to
have hard lockup when running on a debug kernel with a slow memory
freeing path (like with KASAN enabled).

release_task() => flush_sigqueue()

The lockup condition can be reproduced on a large system with a lot of
memory and relatively slow CPUs running LTP's sigqueue_9-1 test on a
debug kernel.

This patchset tries to mitigate this problem by introducing a new kernel
memory freeing queue mechanism modelled after the wake_q mechanism for
waking up tasks. Then flush_sigqueue() and release_task() are modified
to use the freeing queue mechanism to defer the actual memory object
freeing until after releasing the tasklist_lock and with irq re-enabled.

With the patchset applied, the hard lockup problem was no longer
reproducible on the debug kernel.

Waiman Long (4):
mm: Implement kmem objects freeing queue
signal: Make flush_sigqueue() use free_q to release memory
signal: Add free_uid_to_q()
mm: Do periodic rescheduling when freeing objects in kmem_free_up_q()

include/linux/sched/user.h | 3 +++
include/linux/signal.h | 4 ++-
include/linux/slab.h | 28 +++++++++++++++++++++
kernel/exit.c | 12 ++++++---
kernel/signal.c | 29 +++++++++++++---------
kernel/user.c | 17 ++++++++++---
mm/slab_common.c | 50 ++++++++++++++++++++++++++++++++++++++
security/selinux/hooks.c | 8 ++++--
8 files changed, 128 insertions(+), 23 deletions(-)

--
2.18.1

\
 
 \ /
  Last update: 2019-03-21 22:45    [W:0.090 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site