Received: by 10.223.148.5 with SMTP id 5csp6124081wrq; Wed, 17 Jan 2018 09:41:05 -0800 (PST) X-Google-Smtp-Source: ACJfBos44vkYpzRqSIE8YdbNGCtb0FNNmqbptQJaN/s6mPYmNa8ahbjqtbZXCEBFekAsQCq5RdqJ X-Received: by 10.84.211.105 with SMTP id b96mr2850941pli.123.1516210865108; Wed, 17 Jan 2018 09:41:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516210865; cv=none; d=google.com; s=arc-20160816; b=bPN3Tc1yP9xbOvs65wpMsApPy2XFpLUqdvZnLA4mS17lY+NuPuq+LgiEY/E35449U6 wZU4cO9R88jLsZNV/tB76Ie+HiJS0Emr93DOBwcWa+6SVOdYnBYJTlF3Q7U8Rd8TnaxK Ft+vhIwVvLc+rVRIbgid9fTYcZllGyLRrbplP/r20aw7lnj4S+m/maydtf422atrc+xS U4teISnPDoHh/1nL2bAjlCHY9PkDoFkbXDt6VcxWQDyRJ4W634r1Sx+NdGsgsHPYWcwS Svq1TbiGkDK2nMjAIg9+N9UmH3wskOnyJ7dZliu6jjWwOJ8QRmS022sRghFxoBq8ANRi vg/g== 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:arc-authentication-results; bh=HLL3DMcyYZG/qukjdAtXkKKuLC4rqyyxbOA7/xNhV+M=; b=IzFgOflX/TGi8bbw/yKrb9p7XucR2FwAnA+z8lkKgoXXiwgTrWK3IZqd+TcC3CUnnW z4Wk0vGyrtFlM8cGWwlXfTU9jWPVZTU550boQszu9V153JobzcAtYeu0bMnzLOGGxKGF u1IqrRltJlwiLc+KQwJivahPzx53bZMzBTht4JJiNwKR53/qlWiCBuwYx2r+dd35wAC4 IToy/G2w6pECLMkpK1MxT/T0aj89eotWJXiSDG3w6VphgkEYZGBDMEzB5qc5xkKneQgi W8SRWdx7HDm3tSnkYygsmaB8WTi1uIRCTG2jFoZWd39K6EOHS/27+JOys8PFnGzwB85T uWqA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t20si4976492pfl.26.2018.01.17.09.40.51; Wed, 17 Jan 2018 09:41:05 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754031AbeAQRjw (ORCPT + 99 others); Wed, 17 Jan 2018 12:39:52 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:44860 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753225AbeAQRju (ORCPT ); Wed, 17 Jan 2018 12:39:50 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DA82180D; Wed, 17 Jan 2018 09:39:49 -0800 (PST) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5AD043F53D; Wed, 17 Jan 2018 09:39:47 -0800 (PST) Date: Wed, 17 Jan 2018 17:39:44 +0000 From: Dave Martin To: "Eric W. Biederman" Cc: linux-arch@vger.kernel.org, Arnd Bergmann , Nicolas Pitre , Tony Lindgren , Catalin Marinas , Tyler Baicar , Will Deacon , linux-kernel@vger.kernel.org, Oleg Nesterov , James Morse , Al Viro , Olof Johansson , Santosh Shilimkar , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS Message-ID: <20180117173944.GK22781@e103592.cambridge.arm.com> References: <87373b6ghs.fsf@xmission.com> <20180112005940.23279-7-ebiederm@xmission.com> <20180115163028.GU22781@e103592.cambridge.arm.com> <87h8rnox3c.fsf@xmission.com> <20180117171729.GJ22781@e103592.cambridge.arm.com> <87h8rkflft.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h8rkflft.fsf@xmission.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 17, 2018 at 11:24:06AM -0600, Eric W. Biederman wrote: > Dave Martin writes: [...] > > Should si_code simply be ignored for the SIGKILL case? > > I know what x86 does in a similar case is it uses force_sig instead of > force_sig_info. Then the generic code gets to worry about > > If the appropriate paths generic paths get to worry about what siginfo > to fill in in that case. Which for SI_KERNEL is zero for everything > except the si_code and the si_signo. > > That seems perfectly reasonable. OK, I'll go with SI_KERNEL then. Cheers ---Dave