Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Matt Redfearn <matt.redfearn@mips.com>
Cc: <linux-arch@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	James Hogan <jhogan@kernel.org>, <linux-mips@linux-mips.org>
Subject: Re: [REVIEW][PATCH 08/22] signal/mips: Use force_sig_fault where appropriate
Date: Wed, 09 May 2018 21:39:20 -0500	[thread overview]
Message-ID: <8736z0s087.fsf@xmission.com> (raw)
In-Reply-To: <e0a5bde2-7817-3e05-1c8d-c8fa8f6aa5f2@mips.com> (Matt Redfearn's message of "Wed, 9 May 2018 16:14:40 +0100")

Matt Redfearn <matt.redfearn@mips.com> writes:

> Hi Eric,
>
> On 20/04/18 15:37, Eric W. Biederman wrote:
>> Filling in struct siginfo before calling force_sig_info a tedious and
>> error prone process, where once in a great while the wrong fields
>> are filled out, and siginfo has been inconsistently cleared.
>>
>> Simplify this process by using the helper force_sig_fault.  Which
>> takes as a parameters all of the information it needs, ensures
>> all of the fiddly bits of filling in struct siginfo are done properly
>> and then calls force_sig_info.
>>
>> In short about a 5 line reduction in code for every time force_sig_info
>> is called, which makes the calling function clearer.
>>
>> Cc: Ralf Baechle <ralf@linux-mips.org>
>> Cc: James Hogan <jhogan@kernel.org>
>> Cc: linux-mips@linux-mips.org
>> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>> ---
>>   arch/mips/kernel/traps.c | 65 ++++++++++++++----------------------------------
>>   arch/mips/mm/fault.c     | 19 ++++----------
>>   2 files changed, 23 insertions(+), 61 deletions(-)
>>
>> diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
>> index 967e9e4e795e..66ec4b0b484d 100644
>> --- a/arch/mips/kernel/traps.c
>> +++ b/arch/mips/kernel/traps.c
>> @@ -699,17 +699,11 @@ static int simulate_sync(struct pt_regs *regs, unsigned int opcode)
>>   asmlinkage void do_ov(struct pt_regs *regs)
>>   {
>>   	enum ctx_state prev_state;
>> -	siginfo_t info;
>> -
>> -	clear_siginfo(&info);
>> -	info.si_signo = SIGFPE;
>> -	info.si_code = FPE_INTOVF;
>> -	info.si_addr = (void __user *)regs->cp0_epc;
>>     	prev_state = exception_enter();
>>   	die_if_kernel("Integer overflow", regs);
>>   -	force_sig_info(SIGFPE, &info, current);
>> +	force_sig_fault(SIGFPE, FPE_INTOVF, (void __user *)regs->cp0_epc, current);
>>   	exception_exit(prev_state);
>>   }
>>   @@ -722,32 +716,27 @@ asmlinkage void do_ov(struct pt_regs *regs)
>>   void force_fcr31_sig(unsigned long fcr31, void __user *fault_addr,
>>   		     struct task_struct *tsk)
>>   {
>> -	struct siginfo si;
>> -
>> -	clear_siginfo(&si);
>> -	si.si_addr = fault_addr;
>> -	si.si_signo = SIGFPE;
>> +	int si_code;
>
> This is giving build errors in Linux next
> (https://storage.kernelci.org/next/master/next-20180509/mips/defconfig+kselftest/build.log)
>
> si_code would have ended up as 0 before from the clear_siginfo(), but perhaps

And si_code 0 is not a valid si_code to use with a floating point
siginfo layout.

> int si_code = FPE_FLTUNK;
>
> Would make a more sensible default?

FPE_FLTUNK would make a more sensible default.

I seem to remember someone telling me that case can never happen in
practice so I have simply not worried about it.  Perhaps I am
misremembering this.

Eric

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Matt Redfearn <matt.redfearn@mips.com>
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
	Ralf Baechle <ralf@linux-mips.org>,
	James Hogan <jhogan@kernel.org>,
	linux-mips@linux-mips.org
Subject: Re: [REVIEW][PATCH 08/22] signal/mips: Use force_sig_fault where appropriate
Date: Wed, 09 May 2018 21:39:20 -0500	[thread overview]
Message-ID: <8736z0s087.fsf@xmission.com> (raw)
Message-ID: <20180510023920.sEZfJwBy17kH0Gwlh8cQKeraRX8OVDwy3EHL-yA1lcg@z> (raw)
In-Reply-To: <e0a5bde2-7817-3e05-1c8d-c8fa8f6aa5f2@mips.com> (Matt Redfearn's message of "Wed, 9 May 2018 16:14:40 +0100")

Matt Redfearn <matt.redfearn@mips.com> writes:

> Hi Eric,
>
> On 20/04/18 15:37, Eric W. Biederman wrote:
>> Filling in struct siginfo before calling force_sig_info a tedious and
>> error prone process, where once in a great while the wrong fields
>> are filled out, and siginfo has been inconsistently cleared.
>>
>> Simplify this process by using the helper force_sig_fault.  Which
>> takes as a parameters all of the information it needs, ensures
>> all of the fiddly bits of filling in struct siginfo are done properly
>> and then calls force_sig_info.
>>
>> In short about a 5 line reduction in code for every time force_sig_info
>> is called, which makes the calling function clearer.
>>
>> Cc: Ralf Baechle <ralf@linux-mips.org>
>> Cc: James Hogan <jhogan@kernel.org>
>> Cc: linux-mips@linux-mips.org
>> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>> ---
>>   arch/mips/kernel/traps.c | 65 ++++++++++++++----------------------------------
>>   arch/mips/mm/fault.c     | 19 ++++----------
>>   2 files changed, 23 insertions(+), 61 deletions(-)
>>
>> diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
>> index 967e9e4e795e..66ec4b0b484d 100644
>> --- a/arch/mips/kernel/traps.c
>> +++ b/arch/mips/kernel/traps.c
>> @@ -699,17 +699,11 @@ static int simulate_sync(struct pt_regs *regs, unsigned int opcode)
>>   asmlinkage void do_ov(struct pt_regs *regs)
>>   {
>>   	enum ctx_state prev_state;
>> -	siginfo_t info;
>> -
>> -	clear_siginfo(&info);
>> -	info.si_signo = SIGFPE;
>> -	info.si_code = FPE_INTOVF;
>> -	info.si_addr = (void __user *)regs->cp0_epc;
>>     	prev_state = exception_enter();
>>   	die_if_kernel("Integer overflow", regs);
>>   -	force_sig_info(SIGFPE, &info, current);
>> +	force_sig_fault(SIGFPE, FPE_INTOVF, (void __user *)regs->cp0_epc, current);
>>   	exception_exit(prev_state);
>>   }
>>   @@ -722,32 +716,27 @@ asmlinkage void do_ov(struct pt_regs *regs)
>>   void force_fcr31_sig(unsigned long fcr31, void __user *fault_addr,
>>   		     struct task_struct *tsk)
>>   {
>> -	struct siginfo si;
>> -
>> -	clear_siginfo(&si);
>> -	si.si_addr = fault_addr;
>> -	si.si_signo = SIGFPE;
>> +	int si_code;
>
> This is giving build errors in Linux next
> (https://storage.kernelci.org/next/master/next-20180509/mips/defconfig+kselftest/build.log)
>
> si_code would have ended up as 0 before from the clear_siginfo(), but perhaps

And si_code 0 is not a valid si_code to use with a floating point
siginfo layout.

> int si_code = FPE_FLTUNK;
>
> Would make a more sensible default?

FPE_FLTUNK would make a more sensible default.

I seem to remember someone telling me that case can never happen in
practice so I have simply not worried about it.  Perhaps I am
misremembering this.

Eric

  parent reply	other threads:[~2018-05-14  8:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87604mhrnb.fsf@xmission.com>
2018-04-20 14:37 ` [REVIEW][PATCH 08/22] signal/mips: Use force_sig_fault where appropriate Eric W. Biederman
     [not found]   ` <e0a5bde2-7817-3e05-1c8d-c8fa8f6aa5f2@mips.com>
2018-05-10  2:39     ` Eric W. Biederman [this message]
2018-05-10  2:39       ` Eric W. Biederman
     [not found]       ` <6811e06d-ac0d-35a6-7d86-57838d5d7f8e@mips.com>
2018-05-11  2:31         ` Eric W. Biederman
2018-05-11  2:31           ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8736z0s087.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=jhogan@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=matt.redfearn@mips.com \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox