On Jun 10 2007 22:06, Jiri Kosina wrote:
>On Sun, 10 Jun 2007, Folkert van Heusden wrote:
>
>> Signed-of by: Folkert van Heusden <[EMAIL PROTECTED]
>
>This looks broken BTW.
>
>> +printk(KERN_INFO "Sig %d sent to %d owned by %d.%d
>> (%s), sent by pid %d, uid %d\n",
>> +
On Sun, 10 Jun 2007, Folkert van Heusden wrote:
> Signed-of by: Folkert van Heusden <[EMAIL PROTECTED]
This looks broken BTW.
> + printk(KERN_INFO "Sig %d sent to %d owned by %d.%d
> (%s), sent by pid %d, uid %d\n",
> + sig, t->pid, t->uid, t->gid
> > >> >+{
> > >> 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);
> > >
> >
> > Gargh ... why doe
On Thu, 24 May 2007 11:55:03 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 24 May 2007 09:58:35 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > * Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > > Well OK. But vdso-
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> [...] The only add-on change should be to not print SIGKILL events.
ah, that's already included in the version in -mm.
admittedly, the #ifdef __i386__ is quite lame, but there's no generic
safely-try-to-show-code-at-addr function available at the mome
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 24 May 2007 09:58:35 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > Well OK. But vdso-print-fatal-signals.patch is designated
> > > not-for-mainline anyway.
> >
> > btw., why?
>
On Thu, 24 May 2007 09:58:35 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > Well OK. But vdso-print-fatal-signals.patch is designated
> > not-for-mainline anyway.
>
> btw., why?
err, because that's what I decided a year ago. I wonder why ;)
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> Well OK. But vdso-print-fatal-signals.patch is designated
> not-for-mainline anyway.
btw., why? It's very, very useful to distro, early-boot-userspace and
glibc development. The only add-on change should be to not print SIGKILL
events. Otherwise i
> >> >+{
> >> 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);
> >
>
> Gargh ... why does this want to be in
On 5/21/07, Folkert van Heusden <[EMAIL PROTECTED]> 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
Folkert van Heusden 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
> +
> >>> 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(
Folkert van Heusden 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
>>> +*/
>
> >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))
On May 21 2007 13:04, Folkert van Heusden 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 sign
On Sun, May 20, 2007 at 11:20:36PM +0200, Folkert van Heusden wrote:
> > > + switch(sig) {
> > > + case SIGQUIT:
> > > + case SIGILL:
> > > + case SIGTRAP:
> > > + case SIGABRT:
> > > + case SIGBUS:
> > > + case SIGFPE:
> > > + case SIGSEGV:
> > > + case SIGXCPU:
> > > + case SIGXFSZ:
> > > +
> >> + switch(sig) {
> >> + case SIGQUIT:
...
> >> + case SIGSTKFLT:
> >
> > Unconditional? That's definitely a very bad idea. If anything only unhandled
> > signals should be printed this way because some programs use them
> > internally.
> > But I think your list is far too long anyways.
>
Andi Kleen wrote:
>> +switch(sig) {
>> +case SIGQUIT:
>> +case SIGILL:
>> +case SIGTRAP:
>> +case SIGABRT:
>> +case SIGBUS:
>> +case SIGFPE:
>> +case SIGSEGV:
>> +case SIGXCPU:
>> +case SIGXFSZ:
>> +case SIGSYS:
>> +case SIGSTKFLT:
>
> Uncondi
On Sat, 19 May 2007 12:33:04 +0200 (MEST) Andrea Righi <[EMAIL PROTECTED]>
wrote:
> Bernd Eckenfels wrote:
> > In article <[EMAIL PROTECTED]> you wrote:
> >>printk("%s/%d: potentially unexpected fatal signal %d.\n",
> >>current->comm, current->pid, signr);
> >
> > can we
On Sat, 19 May 2007 12:34:01 +0200 (MEST) Andrea Righi <[EMAIL PROTECTED]>
wrote:
> Print informations about userspace processes that fail to allocate new virtual
> memory.
Why is this useful?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
On Mon, May 21, 2007 at 12:24:22AM +0200, Andi Kleen wrote:
> > > But I think your list is far too long anyways.
> >
> > So, which ones would you like to have removed then?
>
> SIGFPE at least and the accounting signals are dubious too. SIGQUIT can
> be also relatively common.
And SIGSEGV and SI
On Sun, 20 May 2007 23:20:36 +0200, Folkert van Heusden wrote:
> > > + switch(sig) {
> > > + case SIGQUIT:
> > > + case SIGILL:
> > > + case SIGTRAP:
> > > + case SIGABRT:
> > > + case SIGBUS:
> > > + case SIGFPE:
> > > + case SIGSEGV:
> > > + case SIGXCPU:
> > > + case SIGXFSZ:
> > > + case
On Sun, May 20, 2007 at 11:20:36PM +0200, Folkert van Heusden wrote:
> > > + switch(sig) {
> > > + case SIGQUIT:
> > > + case SIGILL:
> > > + case SIGTRAP:
> > > + case SIGABRT:
> > > + case SIGBUS:
> > > + case SIGFPE:
> > > + case SIGSEGV:
> > > + case SIGXCPU:
> > > + case SIGXFSZ:
> > > +
> > > + switch(sig) {
> > > + case SIGQUIT:
> > > + case SIGILL:
> > > + case SIGTRAP:
> > > + case SIGABRT:
> > > + case SIGBUS:
> > > + case SIGFPE:
> > > + case SIGSEGV:
> > > + case SIGXCPU:
> > > + case SIGXFSZ:
> > > + case SIGSYS:
> > > + case SIGSTKFLT:
> > Unconditional? That's defi
> > + switch(sig) {
> > + case SIGQUIT:
> > + case SIGILL:
> > + case SIGTRAP:
> > + case SIGABRT:
> > + case SIGBUS:
> > + case SIGFPE:
> > + case SIGSEGV:
> > + case SIGXCPU:
> > + case SIGXFSZ:
> > + case SIGSYS:
> > + case SIGSTKFLT:
>
> Unconditional? That's def
> + switch(sig) {
> + case SIGQUIT:
> + case SIGILL:
> + case SIGTRAP:
> + case SIGABRT:
> + case SIGBUS:
> + case SIGFPE:
> + case SIGSEGV:
> + case SIGXCPU:
> + case SIGXFSZ:
> + case SIGSYS:
> + case SIGSTKFLT:
Unconditional? That's defini
> >> >
> >> > +if (unlikely(sig == SIGQUIT || sig == SIGILL || sig == SIGTRAP
> >> > ||
> >> > +sig == SIGABRT || sig == SIGBUS || sig == SIGFPE ||
> >> > +sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
> >> > +sig == SIGSYS || sig == SIGSTK
On May 20 2007 18:12, Folkert van Heusden wrote:
>> >
>> > + if (unlikely(sig == SIGQUIT || sig == SIGILL || sig == SIGTRAP ||
>> > + sig == SIGABRT || sig == SIGBUS || sig == SIGFPE ||
>> > + sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
>> > + sig == SIGSYS || sig =
> > > I do not see such on i386, so why for x86_64?
> > > >>>So that you know that one of your programs crashed. That's a feature.
> > > >>This feature could be handy for i386 too.
> > > >Since 2.6.18.2 I use this patch. With 2.6.21.1 it still applies altough
> > > >with a small offsets. Works
On Sun, 20 May 2007 13:21:11 +0200
Folkert van Heusden <[EMAIL PROTECTED]> wrote:
> > I do not see such on i386, so why for x86_64?
> > >>>So that you know that one of your programs crashed. That's a feature.
> > >>This feature could be handy for i386 too.
> > >Since 2.6.18.2 I use this patch.
> I do not see such on i386, so why for x86_64?
> >>>So that you know that one of your programs crashed. That's a feature.
> >>This feature could be handy for i386 too.
> >Since 2.6.18.2 I use this patch. With 2.6.21.1 it still applies altough
> >with a small offsets. Works like a charm.
> >
>
Folkert van Heusden a écrit :
I do not see such on i386, so why for x86_64?
So that you know that one of your programs crashed. That's a feature.
This feature could be handy for i386 too.
Since 2.6.18.2 I use this patch. With 2.6.21.1 it still applies altough
with a small offsets. Works like
> >> I do not see such on i386, so why for x86_64?
> >So that you know that one of your programs crashed. That's a feature.
> This feature could be handy for i386 too.
Since 2.6.18.2 I use this patch. With 2.6.21.1 it still applies altough
with a small offsets. Works like a charm.
Signed-off by:
> >> I'm looking for a way to keep track of the processes that fail to
> >> allocate new
> >> virtual memory. What do you think about the following approach
> >> (untested)?
> > Looks like an easy way for users to spam syslogd over and
> > over and over again.
> > At the very least, shouldn't this
Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
>> + printk(KERN_INFO
>> + "out of virtual memory for process %d (%s): total_vm=%lu,
>> uid=%d\n",
>> + current->pid, current->comm, total_vm, current->uid);
>
> And align this one with the print_f
Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
>>printk("%s/%d: potentially unexpected fatal signal %d.\n",
>>current->comm, current->pid, signr);
>
> can we have both KERN_WARNING please?
>
> Gruss
> Bernd
Depends on print_fatal_signals patch.
---
L
Jan Engelhardt wrote:
> On May 19 2007 11:35, Andrea Righi wrote:
>> Jan Engelhardt wrote:
>>> On May 18 2007 13:47, Andi Kleen wrote:
> I do not see such on i386, so why for x86_64?
So that you know that one of your programs crashed. That's a feature.
>>> This feature could be handy for i
On May 19 2007 11:35, Andrea Righi wrote:
>Jan Engelhardt wrote:
>> On May 18 2007 13:47, Andi Kleen wrote:
I do not see such on i386, so why for x86_64?
>>> So that you know that one of your programs crashed. That's a feature.
>>
>> This feature could be handy for i386 too.
>>
>
>What abou
Jan Engelhardt wrote:
> On May 18 2007 13:47, Andi Kleen wrote:
>>> I do not see such on i386, so why for x86_64?
>> So that you know that one of your programs crashed. That's a feature.
>
> This feature could be handy for i386 too.
>
What about your /proc/sys/kernel/print-fatal-signals? it must
On May 18 2007 13:47, Andi Kleen wrote:
>
>> I do not see such on i386, so why for x86_64?
>
>So that you know that one of your programs crashed. That's a feature.
This feature could be handy for i386 too.
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
In article <[EMAIL PROTECTED]> you wrote:
> + printk(KERN_INFO
> + "out of virtual memory for process %d (%s): total_vm=%lu,
> uid=%d\n",
> + current->pid, current->comm, total_vm, current->uid);
And align this one with the print_fatal layout:
printk(KERN_
In article <[EMAIL PROTECTED]> you wrote:
>printk("%s/%d: potentially unexpected fatal signal %d.\n",
>current->comm, current->pid, signr);
can we have both KERN_WARNING please?
Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
Andrea Righi wrote:
> Robin Holt wrote:
>> On Fri, May 18, 2007 at 09:50:03AM +0200, Andrea Righi wrote:
>>> Rik van Riel wrote:
Andrea Righi wrote:
> I'm looking for a way to keep track of the processes that fail to
> allocate new
> virtual memory. What do you think about the foll
Robin Holt wrote:
> On Fri, May 18, 2007 at 09:50:03AM +0200, Andrea Righi wrote:
>> Rik van Riel wrote:
>>> Andrea Righi wrote:
I'm looking for a way to keep track of the processes that fail to
allocate new
virtual memory. What do you think about the following approach
(unteste
> I do not see such on i386, so why for x86_64?
So that you know that one of your programs crashed. That's a feature.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/major
On Fri, May 18, 2007 at 09:50:03AM +0200, Andrea Righi wrote:
> Rik van Riel wrote:
> > Andrea Righi wrote:
> >> I'm looking for a way to keep track of the processes that fail to
> >> allocate new
> >> virtual memory. What do you think about the following approach
> >> (untested)?
> >
> > Looks lik
Rik van Riel wrote:
> Andrea Righi wrote:
>> I'm looking for a way to keep track of the processes that fail to
>> allocate new
>> virtual memory. What do you think about the following approach
>> (untested)?
>
> Looks like an easy way for users to spam syslogd over and
> over and over again.
>
> At
On May 17 2007 14:22, Rik van Riel wrote:
> Andrea Righi wrote:
>> I'm looking for a way to keep track of the processes that fail to allocate
>> new
>> virtual memory. What do you think about the following approach (untested)?
>
> Looks like an easy way for users to spam syslogd over and
> over an
Andrea Righi wrote:
I'm looking for a way to keep track of the processes that fail to allocate new
virtual memory. What do you think about the following approach (untested)?
Looks like an easy way for users to spam syslogd over and
over and over again.
At the very least, shouldn't this be depe
I'm looking for a way to keep track of the processes that fail to allocate new
virtual memory. What do you think about the following approach (untested)?
--
Print informations about the processes that fail to allocate virtual memory.
Signed-off-by: Andrea Righi <[EMAIL PROTECTED]>
diff -urpN li
50 matches
Mail list logo
