Even if the signal was handled using signal(2) the message
would be printed. Fix that by checking whether the signal
is handled.
Signed-off-by: Levente Kurusa <[email protected]>
---
arch/arm/mm/fault.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 0d629b8..bbf5d73 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -164,8 +164,9 @@ __do_user_fault(struct task_struct *tsk, unsigned long addr,
struct siginfo si;
#ifdef CONFIG_DEBUG_USER
- if (((user_debug & UDBG_SEGV) && (sig == SIGSEGV)) ||
- ((user_debug & UDBG_BUS) && (sig == SIGBUS))) {
+ if ((((user_debug & UDBG_SEGV) && (sig == SIGSEGV)) ||
+ ((user_debug & UDBG_BUS) && (sig == SIGBUS))) &&
+ unhandled_signal(tsk, sig)) {
printk(KERN_DEBUG "%s: unhandled page fault (%d) at 0x%08lx, code 0x%03x\n",
tsk->comm, sig, addr, fsr);
show_pte(tsk->mm, addr);
--
2.4.3
On Wed, Jul 15, 2015 at 05:30:50PM +0200, Levente Kurusa wrote:
> Even if the signal was handled using signal(2) the message
> would be printed. Fix that by checking whether the signal
> is handled.
Why?
Even if the application handles the signal, the point of this debugging is
to have the kernel report the reason for the fault.
Just because the application has installed a SIGSEGV handler to print some
nice "oops" message, and to cleanly shut down (eg, like Xorg) doesn't mean
we should hide this debugging. In fact, as such handlers generally get in
the way of getting a decent dump from the application, having the kernel
report this information is even more valuable in this situation.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
Hi,
----- Original Message -----
> On Wed, Jul 15, 2015 at 05:30:50PM +0200, Levente Kurusa wrote:
> > Even if the signal was handled using signal(2) the message
> > would be printed. Fix that by checking whether the signal
> > is handled.
>
> Why?
One of the reasons is that arm64 prints the same message only when the signal
is unhandled.
The other is the message saying "unhandled". :-)
But, don't get me wrong, I found the 'problem' by having a quick glimpse at the code
(even though I have a testcase now...), so if you think this is right this way,
then so be it.
>
> Even if the application handles the signal, the point of this debugging is
> to have the kernel report the reason for the fault.
>
> Just because the application has installed a SIGSEGV handler to print some
> nice "oops" message, and to cleanly shut down (eg, like Xorg) doesn't mean
> we should hide this debugging. In fact, as such handlers generally get in
> the way of getting a decent dump from the application, having the kernel
> report this information is even more valuable in this situation.
I agree, but I find this being controlled by a kernel config option _and_ a
parameter makes it harder to use. Maybe we could switch to the sysctl,
"debug.exception-trace" like some other architectures do? What do you think?
Thanks,
Levente