prints can delay queuing of signal, so better to print
after force_sig_info.
Let's say process generated SIGSEGV , and some other thread sends
SIGKILL to crashing process and it gets queued before SIGSEGV becuase
of little delay due to prints so in this case coredump might not generate.
Signed-off-by: Maninder Singh <[email protected]>
Signed-off-by: Amit Nagal <[email protected]>
Reviewed-by: Ajeet Yadav <[email protected]>
---
arch/arm/mm/fault.c | 18 +++++++++---------
arch/arm64/mm/fault.c | 16 ++++++++--------
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 3a2e678..f92f90b 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -163,6 +163,15 @@ void show_pte(struct mm_struct *mm, unsigned long addr)
{
struct siginfo si;
+ tsk->thread.address = addr;
+ tsk->thread.error_code = fsr;
+ tsk->thread.trap_no = 14;
+ si.si_signo = sig;
+ si.si_errno = 0;
+ si.si_code = code;
+ si.si_addr = (void __user *)addr;
+ force_sig_info(sig, &si, tsk);
+
#ifdef CONFIG_DEBUG_USER
if (((user_debug & UDBG_SEGV) && (sig == SIGSEGV)) ||
((user_debug & UDBG_BUS) && (sig == SIGBUS))) {
@@ -172,15 +181,6 @@ void show_pte(struct mm_struct *mm, unsigned long addr)
show_regs(regs);
}
#endif
-
- tsk->thread.address = addr;
- tsk->thread.error_code = fsr;
- tsk->thread.trap_no = 14;
- si.si_signo = sig;
- si.si_errno = 0;
- si.si_code = code;
- si.si_addr = (void __user *)addr;
- force_sig_info(sig, &si, tsk);
}
void do_bad_area(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index a78a5c4..eb5d0e3 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -197,14 +197,6 @@ static void __do_user_fault(struct task_struct *tsk, unsigned long addr,
{
struct siginfo si;
- if (unhandled_signal(tsk, sig) && show_unhandled_signals_ratelimited()) {
- pr_info("%s[%d]: unhandled %s (%d) at 0x%08lx, esr 0x%03x\n",
- tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
- addr, esr);
- show_pte(tsk->mm, addr);
- show_regs(regs);
- }
-
tsk->thread.fault_address = addr;
tsk->thread.fault_code = esr;
si.si_signo = sig;
@@ -212,6 +204,14 @@ static void __do_user_fault(struct task_struct *tsk, unsigned long addr,
si.si_code = code;
si.si_addr = (void __user *)addr;
force_sig_info(sig, &si, tsk);
+
+ if (unhandled_signal(tsk, sig) && show_unhandled_signals_ratelimited()) {
+ pr_info("%s[%d]: unhandled %s (%d) at 0x%08lx, esr 0x%03x\n",
+ tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
+ addr, esr);
+ show_pte(tsk->mm, addr);
+ show_regs(regs);
+ }
}
static void do_bad_area(unsigned long addr, unsigned int esr, struct pt_regs *regs)
--
1.9.1
On Mon, Dec 19, 2016 at 04:07:12PM +0530, Maninder Singh wrote:
> prints can delay queuing of signal, so better to print
> after force_sig_info.
>
> Let's say process generated SIGSEGV , and some other thread sends
> SIGKILL to crashing process and it gets queued before SIGSEGV becuase
> of little delay due to prints so in this case coredump might not generate.
In any case, that's going to be a race - you can't predict exactly when
the "other thread" will send the SIGKILL in relation to the SIGSEGV.
So, I don't see the point of this change.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
This is unreadable. Sorry.
On Wed, Dec 21, 2016 at 05:59:11AM +0000, AMIT NAGAL wrote:
> <HTML><HEAD>
> <META content="text/html; charset=utf-8" http-equiv=Content-Type>
> <STYLE id=mysingle_style type=text/css>.search-word {
> BACKGROUND-COLOR: #ffee94
> }
> P {
> MARGIN-BOTTOM: 5px; FONT-SIZE: 10pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
> }
> TD {
> MARGIN-BOTTOM: 5px; FONT-SIZE: 10pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
> }
> LI {
> MARGIN-BOTTOM: 5px; FONT-SIZE: 10pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
> }
> BODY {
> FONT-SIZE: 10pt; FONT-FAMILY: Arial, arial
> }
> </STYLE>
>
> <META content=IE=5 http-equiv=X-UA-Compatible>
> <META content=IE=5 http-equiv=X-UA-Compatible>
> <STYLE id=knox_style type=text/css>P {
> MARGIN-BOTTOM: 5px; FONT-SIZE: 10pt; FONT-FAMILY: Arial, arial; MARGIN-TOP: 5px
> }
> </STYLE>
>
> <META content=IE=5 http-equiv=X-UA-Compatible>
> <META name=GENERATOR content="MSHTML 11.00.9600.18500"></HEAD>
> <BODY>
> <P></P>
> <P>Hello,</P><PRE>On Mon, Dec 19, 2016 at 04:07:12PM +0530, Maninder Singh wrote:
> >> prints can delay queuing of signal, so better to print
> >>after force_sig_info.
> >>
> >> Let's say process generated SIGSEGV , and some other thread sends
> >> SIGKILL to crashing process and it gets queued before SIGSEGV becuase
> >> of little delay due to prints so in this case coredump might not generate.
>
> > In any case, that's going to be a race - you can't predict exactly when
> > the "other thread" will send the SIGKILL in relation to the SIGSEGV.
>
> > So, I don't see the point of this change.</PRE><PRE>Actually SIGSEGV queueing gets delayed in __do_user_fault as logs are printed first(show_pte , show_regs).</PRE><PRE>meanwhile if SIGKILL gets queued , SIGSEGV wont be serviced first and coredump will be skipped . </PRE><PRE>so our intention is to queue the SIGSEGV as early as possible . so that the probability of race between</PRE><PRE>SIGKILL and SIGSEGV can be minimized .</PRE><PRE>Amit</PRE><PRE> </PRE><table id=bannersignimg><tr><td><div id="cafe-note-contents" style="margin:10px;font-family:Arial;font-size:10pt;"><p> </p></div></td></tr></table><table id=confidentialsignimg><tr><td><div id="cafe-note-contents" style="margin:10px;font-family:Arial;font-size:10pt;"><p><img unselectable="on" data-cui-image="true" style="display: inline-block; border: 0px solid; width: 520px; height: 144px;" src="cid:[email protected]"><br></p></div></td></tr></table></BODY></HTML><img src='http://ext.samsung.net/mail/ext/v1/external/status/update?userid=amit.nagal&do=bWFpbElEPTIwMTYxMjIxMDU1OTExZXBjbXM1cDExNDZjZWU5MjEyY2MxN2ZhOGQ1YjE4YzQ5YTA4NWRlZiZyZWNpcGllbnRBZGRyZXNzPWxpbnV4QGFybWxpbnV4Lm9yZy51aw__' border=0 width=0 height=0 style='display:none'>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.