Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp651318img; Fri, 22 Mar 2019 05:58:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqwDzQeuZL6fuOebhrobEYi6d5f5oMUlWYaL3TNu9q63fBsN9reQk0S0KNLXnxm2tuUAV014 X-Received: by 2002:a63:3f8b:: with SMTP id m133mr8631489pga.91.1553259488706; Fri, 22 Mar 2019 05:58:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553259488; cv=none; d=google.com; s=arc-20160816; b=FIP/F8nqtz0nD3rIEpyfIMgjycEsI+fA+ikSMNGJqz+EQ7c6vipHdZsYHkNMq0Q4fO 6CbWEuOnPQtlONBYOM9j+ZUqTIffbk8MlUeplLgghigCAlhQIEKXKpFomW/o/Q/12GwN jgPY/SJ+80MkTwFWorWzM52tX3p0u7TA4fwIJCTsYGVBYE58dCptYTzxVKii7i4lctO5 KgcVPGo1WRz21753DgqzILW1u7Oe/c1d6yzwI/OXFOTw6ghmDC2CjSTUk0MgDWVs3hSk WpIk6dIGWqNP0xCIi947MJHX7d9QOKcKlHpwqk9EIGyvh9Adg9mML98lKjiAvGOHAZIF o1JQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=DFg4D3dCP/iRJT6YFn1pQsE7E9H+XSzdonnlFHV49DU=; b=nX68pzaZB52wHzj7BHUbgLUr3JEjq7M0/VSgwXD35v+eb8TLJ3fb2UHpyL5VkyyxnQ tYTsZnoqg/mNsav0eJJ4Upmo7SdbXA/aMskcU6oRHapPCkq31G6wvsC4/xDZn/8k8pMK tZShENTf+n5ixJ2XOrLoGn9mCwsJWQaP8EuMdlYxzHWpputPPO4ehkblQv7FCpfIw8/s UF/EGGJWDR9lMPHMBgazAa3u7HjL2uPIOCMd1tFEEiqa7WkYjqWPX9cjTqF13sQOl1MB G26H8L6CjH1M1JSN/2Rqv+jNOm3icvWIU16cJipDQdBhnHTLS/I8G3Fd9iEi2DY6MZED F2zg== 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 s78si6633269pfa.161.2019.03.22.05.57.53; Fri, 22 Mar 2019 05:58:08 -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 S1730147AbfCVM4I (ORCPT + 99 others); Fri, 22 Mar 2019 08:56:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48956 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732465AbfCVLtZ (ORCPT ); Fri, 22 Mar 2019 07:49:25 -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 758D8A12A7; Fri, 22 Mar 2019 11:49:25 +0000 (UTC) Received: from dhcp-27-174.brq.redhat.com (unknown [10.43.17.32]) by smtp.corp.redhat.com (Postfix) with SMTP id 2DD3417160; Fri, 22 Mar 2019 11:49:20 +0000 (UTC) Received: by dhcp-27-174.brq.redhat.com (nbSMTP-1.00) for uid 1000 oleg@redhat.com; Fri, 22 Mar 2019 12:49:23 +0100 (CET) Date: Fri, 22 Mar 2019 12:49:17 +0100 From: Oleg Nesterov To: Matthew Wilcox Cc: Waiman Long , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , linux-kernel@vger.kernel.org, linux-mm@kvack.org, selinux@vger.kernel.org, Paul Moore , Stephen Smalley , Eric Paris , "Peter Zijlstra (Intel)" Subject: Re: [PATCH 0/4] Signal: Fix hard lockup problem in flush_sigqueue() Message-ID: <20190322114917.GC28876@redhat.com> References: <20190321214512.11524-1-longman@redhat.com> <20190322101535.GA10344@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190322101535.GA10344@bombadil.infradead.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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.27]); Fri, 22 Mar 2019 11:49:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/22, Matthew Wilcox wrote: > > On Thu, Mar 21, 2019 at 05:45:08PM -0400, Waiman Long wrote: > > 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). > > I appreciate these are "reliable" signals, but why do we accumulate so > many signals to a task which will never receive them? Can we detect at > signal delivery time that the task is going to die and avoid queueing > them in the first place? A task can block the signal and accumulate up to RLIMIT_SIGPENDING signals, then it can exit. Oleg.