lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a781481a0705231100q333a589at6c025eb1292019cd@mail.gmail.com>
Date:	Wed, 23 May 2007 23:30:50 +0530
From:	"Satyam Sharma" <satyam.sharma@...il.com>
To:	"Folkert van Heusden" <folkert@...heusden.com>
Cc:	"Jan Engelhardt" <jengelh@...ux01.gwdg.de>,
	"Andrea Righi" <righiandr@...rs.sourceforge.net>,
	"Andi Kleen" <ak@...e.de>,
	"Stephen Hemminger" <shemminger@...ux-foundation.org>,
	"Eric Dumazet" <dada1@...mosbay.com>,
	"Rik van Riel" <riel@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: signals logged / [RFC] log out-of-virtual-memory events

On 5/21/07, Folkert van Heusden <folkert@...heusden.com> wrote:
> > >What about the following enhancement: I check with sig_fatal if it would
> > >kill the process and only then emit a message. So when an application
> > >takes care itself of handling it nothing is printed.
> > >+    /* emit some logging for unhandled signals
> > >+     */
> > >+    if (sig_fatal(t, sig))
> > Not unhandled_signal()?
>
> Can we already use that one in send_signal? As the signal needs to be
> send first I think before we know if it was handled or not? sig_fatal
> checks if the handler is set to default - which is it is not taken care
> of.
>
> > >+    {
> > if (sig_fatal(t, sig)) {
> > >+            printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
> > s/send/sent/;
> > >+            sig, t -> pid, t -> uid, t -> gid, t -> comm);
> > t->pid, t->uid, t->gid, t->comm);
>
>
> Description:
> This patch adds code to the signal-sender making it log a message when
> an unhandled fatal signal will be delivered.

Gargh ... why does this want to be in the *kernel*'s logs? In any case, can
you please make this KERN_INFO (or lower) instead of KERN_WARNING.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ