linux-next: manual merge of the userns tree with the mips tree
Subsystems (2)
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
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.cbetween commit:
260a789828aa("MIPS: signal: Remove unreachable code fromforce_fcr31_sig().")from the mips tree and commit:
ea1b75cf9138("signal/mips: Document a conflict withSI_USERwith 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
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.cbetween commit:
260a789828aa("MIPS: signal: Remove unreachable code fromforce_fcr31_sig().")from the mips tree and commit:
ea1b75cf9138("signal/mips: Document a conflict withSI_USERwith 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 withSI_USERwith 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 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
@@ -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
@@ -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
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.cbetween commit:
260a789828aa("MIPS: signal: Remove unreachable code fromforce_fcr31_sig().")from the mips tree and commit:
ea1b75cf9138("signal/mips: Document a conflict withSI_USERwith 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