Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp87634img; Thu, 21 Mar 2019 14:47:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqzXSzV9u5Cg5eO0TsiuLBtDzwT5kV09KtmldY7yaa3g5CAsWgH7I4k9QwozN1Sem/uDE4l3 X-Received: by 2002:a17:902:248:: with SMTP id 66mr5996647plc.286.1553204870227; Thu, 21 Mar 2019 14:47:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553204870; cv=none; d=google.com; s=arc-20160816; b=W2L9OWzGdsqjrgMWbZyty84gnK/ZAkw/zRNXzLK9wyKj0k7yI2hjL0/kaWa3+IhBe+ AGY2SWN9EDeeeQBxp8ByRecllpJMl/PNhaoZdhk6GlVdQm55Ern47ua0Bp9Bb8WWQMup 2TF6IL72fNCTK/GOadxrLYlWJihK9P6s7Dvsox72Mv8dbCjBKN0XthAj/Q36mkwMs38j BQtJbGvxXXZAR7b8rFrYilSAk4XPbFs5g9IqYXlFscQZv2I+ytZ8zzUmShFpvWogDMiL hCKpXMniz6Cet1EvVIhzPoi8uWoHcaQIaol7uSV57wKDinPs1D9EwbXojoVVPzqcsT5B UpvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=oVlIazTHKce+tMnlJcR9AELncx++OlgJ6EkW+5kGuBo=; b=EHObk6PRTJ3qRd8UC5N4iwkXZ9+JH6rx1hII7NFRxg+kXs+50PC3PJjAomAzXVUtQ4 Eyz4wJC/XYAkqRjUBA3QTrbzDP4RPZw4QpV6NJJYrs2Z+3B3ibzjecRwktPlyIWV2O/d xx4G4q3PjYLPIVmsdAEOfLej1w1aSi5U9UjkzA1JeBWQd+1QisQ4y5mBX6CHZH5eWftW vSxWSJCBfH+cALOk7A0kIdqurD2BD4YmjcdhXH8VV8QQRwiQqpMZn2V4QHSgHkBP2rXb pZa71R5oaidm1yzSacDS9W/F/R+34IOy/7+P1oej8w+y6jZ0D0NIXyJu6PeuqGH+yccp lJeQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d3si5519745pla.399.2019.03.21.14.47.35; Thu, 21 Mar 2019 14:47:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727142AbfCUVph (ORCPT + 99 others); Thu, 21 Mar 2019 17:45:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50664 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725962AbfCUVph (ORCPT ); Thu, 21 Mar 2019 17:45:37 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DA86A59443; Thu, 21 Mar 2019 21:45:35 +0000 (UTC) Received: from llong.com (dhcp-17-47.bos.redhat.com [10.18.17.47]) by smtp.corp.redhat.com (Postfix) with ESMTP id 845765C8BD; Thu, 21 Mar 2019 21:45:27 +0000 (UTC) From: Waiman Long To: Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, selinux@vger.kernel.org, Paul Moore , Stephen Smalley , Eric Paris , "Peter Zijlstra (Intel)" , Oleg Nesterov , Waiman Long Subject: [PATCH 0/4] Signal: Fix hard lockup problem in flush_sigqueue() Date: Thu, 21 Mar 2019 17:45:08 -0400 Message-Id: <20190321214512.11524-1-longman@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 21 Mar 2019 21:45:36 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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