linux-next: manual merge of the userns tree with the mips tree

linux-next: manual merge of the userns tree with the mips tree

[Stephen Rothwell]

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in:

  arch/mips/kernel/traps.c

between commit:

  260a789828aa ("MIPS: signal: Remove unreachable code from force_fcr31_sig().")

from the mips tree and commit:

  ea1b75cf9138 ("signal/mips: Document a conflict with SI_USER with SIGFPE")

from the userns tree.

I fixed it up (the former removed the code updated by the latter) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the userns tree with the mips tree

[Ralf Baechle]

On Tue, Aug 08, 2017 at 03:10:04PM +1000, Stephen Rothwell wrote:

(Maciej added to cc.)

> Hi Eric,
> 
> Today's linux-next merge of the userns tree got a conflict in:
> 
>   arch/mips/kernel/traps.c
> 
> between commit:
> 
>   260a789828aa ("MIPS: signal: Remove unreachable code from force_fcr31_sig().")
> 
> from the mips tree and commit:
> 
>   ea1b75cf9138 ("signal/mips: Document a conflict with SI_USER with SIGFPE")
> 
> from the userns tree.
> 
> I fixed it up (the former removed the code updated by the latter) and
> can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.

Eric,

after yesterday's emails on the topic I think commit ea1b75cf9138 ("signal/
mips: Document a conflict with SI_USER with SIGFPE") should be dropped.

  Ralf

Re: linux-next: manual merge of the userns tree with the mips tree

[Eric W. Biederman]

Ralf Baechle <ralf@linux-mips.org> writes:

> On Tue, Aug 08, 2017 at 03:10:04PM +1000, Stephen Rothwell wrote:
>
> (Maciej added to cc.)
>
>> Hi Eric,
>> 
>> Today's linux-next merge of the userns tree got a conflict in:
>> 
>>   arch/mips/kernel/traps.c
>> 
>> between commit:
>> 
>>   260a789828aa ("MIPS: signal: Remove unreachable code from force_fcr31_sig().")
>> 
>> from the mips tree and commit:
>> 
>>   ea1b75cf9138 ("signal/mips: Document a conflict with SI_USER with SIGFPE")
>> 
>> from the userns tree.
>> 
>> I fixed it up (the former removed the code updated by the latter) and
>> can carry the fix as necessary. This is now fixed as far as linux-next
>> is concerned, but any non trivial conflicts should be mentioned to your
>> upstream maintainer when your tree is submitted for merging.  You may
>> also want to consider cooperating with the maintainer of the conflicting
>> tree to minimise any particularly complex conflicts.
>
> Eric,
>
> after yesterday's emails on the topic I think commit ea1b75cf9138 ("signal/
> mips: Document a conflict with SI_USER with SIGFPE") should be
> dropped.


I have a follow on change I am about to post and would like to carry
that replaces force_sig_info with force_sig_fault.  So force_fcr31_sig
winds up looking like:

void force_fcr31_sig(unsigned long fcr31, void __user *fault_addr,
		     struct task_struct *tsk)
{
	int si_code;

	if (fcr31 & FPU_CSR_INV_X)
		si_code = FPE_FLTINV;
	else if (fcr31 & FPU_CSR_DIV_X)
		si_code = FPE_FLTDIV;
	else if (fcr31 & FPU_CSR_OVF_X)
		si_code = FPE_FLTOVF;
	else if (fcr31 & FPU_CSR_UDF_X)
		si_code = FPE_FLTUND;
	else if (fcr31 & FPU_CSR_INE_X)
		si_code = FPE_FLTRES;
	else
		si_code = FPE_FIXME;
	force_sig_fault(SIGFPE, si_code, fault_addr, tsk);
}

Which causes gcc to complain if the last else clause is dropped.

Would you be happy if the function wound up looking like:

void force_fcr31_sig(unsigned long fcr31, void __user *fault_addr,
		     struct task_struct *tsk)
{
	int si_code;

	if (fcr31 & FPU_CSR_INV_X)
		si_code = FPE_FLTINV;
	else if (fcr31 & FPU_CSR_DIV_X)
		si_code = FPE_FLTDIV;
	else if (fcr31 & FPU_CSR_OVF_X)
		si_code = FPE_FLTOVF;
	else if (fcr31 & FPU_CSR_UDF_X)
		si_code = FPE_FLTUND;
	else if (fcr31 & FPU_CSR_INE_X)
		si_code = FPE_FLTRES;
	else
		return; /* Broken hardware? */

	force_sig_fault(SIGFPE, si_code, fault_addr, tsk);
}

As it is now clear that code path should never happen I will be happy to
queue change that effectively reverts of ea1b75cf9138 ("signal/mips:
Document a conflict with SI_USER with SIGFPE") and just returns from
force_fcr32_sig in that case.

Eric

[PATCH] mips/signal: In force_fcr31_sig return in the impossible case

[Eric W. Biederman]

In a recent discussion Maciej Rozycki reported that this case is
impossible.

Handle the impossible case by just returning instead of trying to
handle it.  This makes static analysis simpler as it means nothing
needs to consider the impossible case after the return statement.

As the code no longer has to deal with this case remove FPE_FIXME from
the mips siginfo.h

Cc: "Maciej W. Rozycki" <macro@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Link: http://lkml.kernel.org/r/20170718140651.15973-4-ebiederm@xmission.com
Ref: ea1b75cf9138 ("signal/mips: Document a conflict with SI_USER with SIGFPE")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 arch/mips/include/uapi/asm/siginfo.h | 7 -------
 arch/mips/kernel/traps.c             | 2 +-
 2 files changed, 1 insertion(+), 8 deletions(-)

Ralf, unless someone objects this is the patch I plan on merging into my
tree, and building up.

diff --git a/arch/mips/include/uapi/asm/siginfo.h b/arch/mips/include/uapi/asm/siginfo.h
index 22a86d84a504..cf6113bbcb98 100644
--- a/arch/mips/include/uapi/asm/siginfo.h
+++ b/arch/mips/include/uapi/asm/siginfo.h
@@ -123,11 +123,4 @@ typedef struct siginfo {
 #define SI_TIMER	-3	/* sent by timer expiration */
 #define SI_MESGQ	-4	/* sent by real time mesq state change */
 
-/*
- * SIGFPE si_codes
- */
-#ifdef __KERNEL__
-#define FPE_FIXME	0	/* Broken dup of SI_USER */
-#endif /* __KERNEL__ */
-
 #endif /* _UAPI_ASM_SIGINFO_H */
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 6c9cca9c5341..2bf414993347 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -735,7 +735,7 @@ void force_fcr31_sig(unsigned long fcr31, void __user *fault_addr,
 	else if (fcr31 & FPU_CSR_INE_X)
 		si.si_code = FPE_FLTRES;
 	else
-		si.si_code = FPE_FIXME;
+		return; /* Broken hardware? */
 	force_sig_info(SIGFPE, &si, tsk);
 }
 
-- 
2.10.1

Re: linux-next: manual merge of the userns tree with the mips tree

[Stephen Rothwell]

Hi all,

On Tue, 8 Aug 2017 15:10:04 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the userns tree got a conflict in:
> 
>   arch/mips/kernel/traps.c
> 
> between commit:
> 
>   260a789828aa ("MIPS: signal: Remove unreachable code from force_fcr31_sig().")
> 
> from the mips tree and commit:
> 
>   ea1b75cf9138 ("signal/mips: Document a conflict with SI_USER with SIGFPE")
> 
> from the userns tree.
> 
> I fixed it up (the former removed the code updated by the latter) and
> can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.

Just a reminder that the above conflict still exists.
-- 
Cheers,
Stephen Rothwell