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,
> > >> >+{
> > >> 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
+{
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 the *kernel*'s logs? In
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, t-comm,
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 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
* 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
* 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
* 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 it's
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 ;)
Perhaps
* 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?
err, because that's
* 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
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-print-fatal-signals.patch
> >> >+{
> >> 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
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
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 unhandled
+{
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 the *kernel*'s logs? In any case,
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
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
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:
>
>
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:
Unconditional? That's definitely
+ 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.
Maybe you could
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:
+ case SIGSYS:
+ case
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 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))
Not
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
+*/
+ if
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
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
+ */
+ if (sig_fatal(t,
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
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
> > + 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
> + 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
> >> >
> >> > +if (unlikely(sig == SIGQUIT || sig == SIGILL || sig == SIGTRAP
> >> > ||
> >> > +sig == SIGABRT || sig == SIGBUS || sig == SIGFPE ||
> >> > +sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
> >> > +sig == SIGSYS || sig ==
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
> 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.
> >
>
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:
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. With 2.6.21.1 it
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.
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 == SIGSTKFLT))
+if (unlikely(sig == SIGQUIT || sig == SIGILL || sig == SIGTRAP
||
+sig == SIGABRT || sig == SIGBUS || sig == SIGFPE ||
+sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
+sig == SIGSYS || sig == SIGSTKFLT))
+{
+ 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 definitely a very
+ 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 definitely a very bad idea.
+ 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 definitely a very bad idea. If anything
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:
+ case SIGSYS:
+ case
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 SIGSYS:
+ case SIGSTKFLT:
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 SIGBUS -
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 have both
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 [EMAIL
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
> >> 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
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.
---
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
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
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
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
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
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 be set
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 about your
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 i386 too.
What
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.
---
Limit the rate
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_fatal layout:
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 be dependant on
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
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:
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
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
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
> 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
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
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.
>
>
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
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 and over
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 the very
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 like an easy way for
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
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
(untested)?
Looks like an
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 following approach
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_WARNING
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 body of a
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
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
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
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
100 matches
Mail list logo
