[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87d0k9gqt3.fsf@xmission.com>
Date: Thu, 23 May 2019 09:59:20 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Will Deacon <will.deacon@....com>
Cc: linux-kernel@...r.kernel.org,
Linux Containers <containers@...ts.linux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>, linux-arch@...r.kernel.org,
Dave Martin <Dave.Martin@....com>,
James Morse <james.morse@....com>
Subject: Re: [REVIEW][PATCH 03/26] signal/arm64: Use force_sig not force_sig_fault for SIGKILL
Will Deacon <will.deacon@....com> writes:
> On Wed, May 22, 2019 at 07:38:53PM -0500, Eric W. Biederman wrote:
>> It really only matters to debuggers but the SIGKILL does not have any
>> si_codes that use the fault member of the siginfo union. Correct this
>> the simple way and call force_sig instead of force_sig_fault when the
>> signal is SIGKILL.
>>
>> Cc: stable@...r.kernel.org
>> Cc: Dave Martin <Dave.Martin@....com>
>> Cc: James Morse <james.morse@....com>
>> Cc: Will Deacon <will.deacon@....com>
>> Fixes: af40ff687bc9 ("arm64: signal: Ensure si_code is valid for all fault signals")
>> Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>> ---
>> arch/arm64/kernel/traps.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
>> index ade32046f3fe..0feb17bdcaa0 100644
>> --- a/arch/arm64/kernel/traps.c
>> +++ b/arch/arm64/kernel/traps.c
>> @@ -282,6 +282,11 @@ void arm64_notify_die(const char *str, struct pt_regs *regs,
>> current->thread.fault_address = 0;
>> current->thread.fault_code = err;
>>
>> + if (signo == SIGKILL) {
>> + arm64_show_signal(signo, str);
>> + force_sig(signo, current);
>> + return;
>> + }
>
> I know it's a bit of a misnomer, but I'd rather do this check inside
> arm64_force_sig_fault, since I think we have other callers (e.g.
> do_bad_area()) which also blindly pass in SIGKILL here.
Sigh. You are right.
I thought I had checked for that when I made my change there. But
do_bad_area will definitely do that, and that was one of the cases that
jumped out at me as needing to be fixed, when I skimmed the arm code.
I will respin this patch to move that lower.
> We could rename the thing if necessary.
I would not mind but as long as we aren't misusing the generic bits
I won't have alarm bells going of in my head when I look at their
users.
Eric
Powered by blists - more mailing lists