Skip to contentSkip to conversation

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

PATCH New Stephen Rothwell 3 participants 5 messages Aug 8, 2017 – Sep 5, 2017

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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.

Signature · 2 lines
Cheers,
Stephen Rothwell
#1 lore raw

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

(Maciej added to cc.)

Quoted 14 lines

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")

Quoted 8 lines

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

#2 lore raw
Quoted 27 lines · Ralf Baechle

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

(Maciej added to cc.)

Quoted 14 lines

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")

Quoted 8 lines

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.

Quoted 5 lines

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

#3 lore raw

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

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

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

---
 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.

arch/mips/include/uapi/asm/siginfo.h +0 -7
index 22a86d84a504..cf6113bbcb98 100644
@@ -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 */
arch/mips/kernel/traps.c +1 -1
index 6c9cca9c5341..2bf414993347 100644
@@ -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);
 }
 
Signature · 1 line
2.10.1
#4 lore raw
In reply to Stephen Rothwell

Hi all,

Quoted 13 lines · On Tue, 8 Aug 2017 15:10:04 +1000 Stephen Rothwell <[email protected]> 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")

Quoted 8 lines

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.

Signature · 2 lines
Cheers,
Stephen Rothwell