From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754160AbeAQRZF (ORCPT ); Wed, 17 Jan 2018 12:25:05 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:38788 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753142AbeAQRZB (ORCPT ); Wed, 17 Jan 2018 12:25:01 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Dave Martin 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 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> Date: Wed, 17 Jan 2018 11:24:06 -0600 In-Reply-To: <20180117171729.GJ22781@e103592.cambridge.arm.com> (Dave Martin's message of "Wed, 17 Jan 2018 17:17:29 +0000") Message-ID: <87h8rkflft.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1ebrSM-0004mF-UO;;;mid=<87h8rkflft.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=97.121.73.102;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+MGQrt+sQMUbJ34qrOnuN0ojfCFHREdz4= X-SA-Exim-Connect-IP: 97.121.73.102 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Dave Martin X-Spam-Relay-Country: X-Spam-Timing: total 268 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.4 (0.9%), b_tie_ro: 1.74 (0.7%), parse: 0.73 (0.3%), extract_message_metadata: 10 (3.9%), get_uri_detail_list: 1.74 (0.6%), tests_pri_-1000: 6 (2.3%), tests_pri_-950: 1.20 (0.4%), tests_pri_-900: 1.04 (0.4%), tests_pri_-400: 25 (9.2%), check_bayes: 24 (8.8%), b_tokenize: 8 (3.0%), b_tok_get_all: 8 (3.2%), b_comp_prob: 2.4 (0.9%), b_tok_touch_all: 2.8 (1.1%), b_finish: 0.53 (0.2%), tests_pri_0: 215 (80.2%), check_dkim_signature: 0.48 (0.2%), check_dkim_adsp: 2.7 (1.0%), tests_pri_500: 3.9 (1.5%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dave Martin writes: > On Mon, Jan 15, 2018 at 11:23:03AM -0600, Eric W. Biederman wrote: >> Dave Martin writes: >> >> > On Thu, Jan 11, 2018 at 06:59:36PM -0600, Eric W. Biederman wrote: > > [...] > >> >> Possible ABI fixes include: >> >> - Send the signal without siginfo >> >> - Don't generate a signal > > [...] > >> >> - Possibly assign and use an appropriate si_code >> >> - Don't handle cases which can't happen >> > >> > I think a mixture of these two is the best approach. >> > >> > In any case, si_code == 0 here doesn't seem to have any explicit meaning. >> > I think we can translate all of the arm64 faults to proper si_codes -- >> > see my sketch below. Probably means a bit more thought though. > > [...] > >> >> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c > > [...] > >> >> @@ -607,70 +607,70 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs) >> >> } >> >> >> >> static const struct fault_info fault_info[] = { >> >> - { do_bad, SIGBUS, 0, "ttbr address size fault" }, >> >> - { do_bad, SIGBUS, 0, "level 1 address size fault" }, >> >> - { do_bad, SIGBUS, 0, "level 2 address size fault" }, >> >> - { do_bad, SIGBUS, 0, "level 3 address size fault" }, > > If I convert this kind of thing to SIGKILL there really is nothing > sensible to put in si_code, except possibly SI_KERNEL (indicating that > the kill did not come from userspace). Even so, it hardly seems worth > filling in fields like si_pid and si_uid just to make this "correct". > > In any case, if siginfo is never seen by userspace for SIGKILL this is > moot. > > Obviously, siginfo is never copied to the user stack in that case, but > is it also guaranteed not to be visible to userspace by other means? > For ptrace I'm hoping not, since SIGKILL should nuke the tracee > immediately instead of being reported to the tracer as a > signal-delivery-stop -- so the tracer should get WIFSIGNALED() && > WTERMSIG() == SIGKILL. A subsequent PTRACE_GETSIGINFO would fail with > ESRCH. > > Does that match your understanding? > > If so, there is some merit in not pretending to pass a reall value > for si_code. > > 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. Eric