log out-of-virtual-memory events

RFC In review Andrea Righi 16 participants 53 messages May 17, 2007 – Jun 10, 2007

Subsystems (2)

Memory management Memory mapping

lore

Share & tools

lore

Andrea Righi

author

2007-05-17 16:24 UTC #0 lore raw

RFC 1/1 log out-of-virtual-memory events

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]>

mm/mmap.c +21 -0

diff -urpN linux-2.6.21/mm/mmap.c linux-2.6.21-vm-log-enomem/mm/mmap.c
@@ -77,6 +77,26 @@ int sysctl_max_map_count __read_mostly =
 atomic_t vm_committed_space = ATOMIC_INIT(0);
 
 /*
+ * Print current process informations when it fails to allocate new virtual
+ * memory.
+ */
+static inline void log_vm_enomem(void)
+{
+	unsigned long total_vm = 0;
+	struct mm_struct *mm;
+
+	task_lock(current);
+	mm = current->mm;
+	if (mm)
+		total_vm = mm->total_vm;
+	task_unlock(current);
+
+	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);
+}
+
+/*
  * Check that a process has enough memory to allocate a new virtual
  * mapping. 0 means there is enough memory for the allocation to
  * succeed and -ENOMEM implies there is not.

@@ -175,6 +195,7 @@ int __vm_enough_memory(long pages, int c
 		return 0;
 error:
 	vm_unacct_memory(pages);
+	log_vm_enomem();
 
 	return -ENOMEM;
 }

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Rik van Riel

2007-05-17 18:22 UTC #1 lore raw

Quoted 2 lines · Andrea Righi

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 print_fatal_signals?

Signature · 9 lines

Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Jan Engelhardt

2007-05-18 06:28 UTC #2 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 9 lines · Rik van Riel

Quoted 3 lines · Andrea Righi
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 print_fatal_signals?

Speaking of signals, everytime I get a segfault (or force one with a test program) on x86_64, the kernel prints to dmesg:

fail[22278]: segfault at 0000000000000000 rip 00000000004004b8 rsp 00007ffff7ecda50 error 6

I do not see such on i386, so why for x86_64?

Jan

Signature · 5 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andi Kleen

2007-05-18 11:47 UTC #3 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 1 line

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

Jan Engelhardt

2007-05-19 07:46 UTC #4 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 4 lines · Andi Kleen

Quoted 2 lines
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

Signature · 5 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andrea Righi

author

2007-05-19 09:35 UTC #5 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 6 lines · Jan Engelhardt

Quoted 2 lines · Andi Kleen
Quoted 1 line
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 to 1 to enable that feature.

-Andrea

Jan Engelhardt

2007-05-19 10:06 UTC #6 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 10 lines · Andrea Righi

Quoted 6 lines · Jan Engelhardt
Quoted 2 lines · Andi Kleen
Quoted 1 line
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 to 1 to enable that feature.

That file does not exist on versions
2.6.18 <= version <= 2.6.20

Jan

Signature · 5 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andrea Righi

author

2007-05-19 10:16 UTC #7 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 4 lines · Jan Engelhardt

Quoted 3 lines · Andrea Righi
Quoted 2 lines · Jan Engelhardt
Quoted 1 line · Andi Kleen
Quoted 1 line
I do not see such on i386, so why for x86_64?

Quoted 9 lines

Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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 to 1 to enable that feature.
That file does not exist on versions
2.6.18 <= version <= 2.6.20

This means that you must apply the print_fatal_signals patch...

-Andrea

Folkert van Heusden

2007-05-20 00:14 UTC #8 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

In reply to Jan Engelhardt

Quoted 3 lines

Quoted 2 lines
Quoted 1 line
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: Folkert van Heusden <[email protected]>

kernel/signal.c 2006-11-17 15:59:13.000000000 +0100 renamed from kernel/signal.c 2006-11-04 02:33:58.000000000 +0100 +9 -0

@@ -706,6 +706,15 @@
        struct sigqueue * q = NULL;
        int ret = 0;
 
+       if (sig == SIGQUIT || sig == SIGILL  || sig == SIGTRAP ||
+           sig == SIGABRT || sig == SIGBUS  || sig == SIGFPE  ||
+           sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
+           sig == SIGSYS  || sig == SIGSTKFLT)
+       {
+               printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
+                       sig, t -> pid, t -> uid, t -> gid, t -> comm);
+       }
+
        /*
         * fast-pathed signals for kernel-internal things like SIGSTOP
         * or SIGKILL.

Folkert van Heusden

Signature · 9 lines

www.biglumber.com <- site where one can exchange PGP key signatures 
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Eric Dumazet

2007-05-20 03:55 UTC #9 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Folkert van Heusden a ecrit :

Quoted 15 lines

Quoted 3 lines
Quoted 2 lines
Quoted 1 line
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: Folkert van Heusden <[email protected]>
kernel/signal.c 2006-11-17 15:59:13.000000000 +0100 renamed from kernel/signal.c 2006-11-04 02:33:58.000000000 +0100 +0 -0
@@ -706,6 +706,15 @@
        struct sigqueue * q = NULL;
        int ret = 0;

kernel/signal.c 2006-11-17 15:59:13.000000000 +0100 line 717

Quoted 10 lines

kernel/signal.c 2006-11-17 15:59:13.000000000 +0100 renamed from kernel/signal.c 2006-11-04 02:33:58.000000000 +0100 +9 -0

 
+       if (sig == SIGQUIT || sig == SIGILL  || sig == SIGTRAP ||
+           sig == SIGABRT || sig == SIGBUS  || sig == SIGFPE  ||
+           sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
+           sig == SIGSYS  || sig == SIGSTKFLT)
+       {
+               printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
+                       sig, t -> pid, t -> uid, t -> gid, t -> comm);
+       }
+

Please check line 219 of Documentation/CodingStyle, Section 3.1: Spaces

	and no space around the '.' and "->" structure member operators.

Thank you

Folkert van Heusden

2007-05-20 11:21 UTC #10 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 9 lines

Quoted 9 lines
Quoted 3 lines
Quoted 2 lines
Quoted 1 line
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: Folkert van Heusden <[email protected]>
kernel/signal.c 2006-11-17 15:59:13.000000000 +0100 renamed from kernel/signal.c 2006-11-04 02:33:58.000000000 +0100 +0 -0

...

Quoted 4 lines

Quoted 1 line
+ sig, t -> pid, t -> uid, t -> gid, t -> comm);
Please check line 219 of Documentation/CodingStyle, Section 3.1: Spaces
	and no space around the '.' and "->" structure member operators.

New version without the spaces around '->' and a nice 'unlikely' added.

Signed-off by: Folkert van Heusden <[email protected]>

kernel/signal.c +9 -0

@@ -706,6 +706,15 @@
 	struct sigqueue * q = NULL;
 	int ret = 0;
 
+	if (unlikely(sig == SIGQUIT || sig == SIGILL  || sig == SIGTRAP ||
+	    sig == SIGABRT || sig == SIGBUS  || sig == SIGFPE  ||
+	    sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
+	    sig == SIGSYS  || sig == SIGSTKFLT))
+	{
+		printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
+			sig, t->pid, t->uid, t->gid, t->comm);
+	}
+
 	/*
 	 * fast-pathed signals for kernel-internal things like SIGSTOP
 	 * or SIGKILL.

Folkert van Heusden

Signature · 11 lines

MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen
kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff-
view', vs.  http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Stephen Hemminger

2007-05-20 16:08 UTC #11 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 39 lines · On Sun, 20 May 2007 13:21:11 +0200 Folkert van Heusden…

Quoted 9 lines
Quoted 9 lines
Quoted 3 lines
Quoted 2 lines
Quoted 1 line
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: Folkert van Heusden <[email protected]>
kernel/signal.c 2006-11-17 15:59:13.000000000 +0100 renamed from kernel/signal.c 2006-11-04 02:33:58.000000000 +0100 +0 -0
...
Quoted 4 lines
Quoted 1 line
+ sig, t -> pid, t -> uid, t -> gid, t -> comm);
Please check line 219 of Documentation/CodingStyle, Section 3.1: Spaces
	and no space around the '.' and "->" structure member operators.
New version without the spaces around '->' and a nice 'unlikely' added.
Signed-off by: Folkert van Heusden <[email protected]>
kernel/signal.c +9 -0
@@ -706,6 +706,15 @@
 	struct sigqueue * q = NULL;
 	int ret = 0;
 
+	if (unlikely(sig == SIGQUIT || sig == SIGILL  || sig == SIGTRAP ||
+	    sig == SIGABRT || sig == SIGBUS  || sig == SIGFPE  ||
+	    sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
+	    sig == SIGSYS  || sig == SIGSTKFLT))
+	{
+		printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
+			sig, t->pid, t->uid, t->gid, t->comm);
+	}
+
 	/*
 	 * fast-pathed signals for kernel-internal things like SIGSTOP
 	 * or SIGKILL.

Quoted 2 lines

Folkert van Heusden

Would turning that into a switch() generate better code.

Signature · 7 lines

Stephen Hemminger <[email protected]>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Folkert van Heusden

2007-05-20 16:12 UTC #12 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 22 lines

Quoted 22 lines
Quoted 9 lines
Quoted 9 lines
Quoted 3 lines
Quoted 2 lines
Quoted 1 line
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: Folkert van Heusden <[email protected]>
kernel/signal.c 2006-11-17 15:59:13.000000000 +0100 renamed from kernel/signal.c 2006-11-04 02:33:58.000000000 +0100 +0 -0
...
Quoted 4 lines
Quoted 1 line
+ sig, t -> pid, t -> uid, t -> gid, t -> comm);
Please check line 219 of Documentation/CodingStyle, Section 3.1: Spaces
	and no space around the '.' and "->" structure member operators.
New version without the spaces around '->' and a nice 'unlikely' added. Signed-off by: Folkert van Heusden <[email protected]>
kernel/signal.c +0 -0
@@ -706,6 +706,15 @@
 	struct sigqueue * q = NULL;
 	int ret = 0;
 

Quoted 14 lines

kernel/signal.c line 720

Quoted 12 lines

kernel/signal.c +9 -0

+	if (unlikely(sig == SIGQUIT || sig == SIGILL  || sig == SIGTRAP ||
+	    sig == SIGABRT || sig == SIGBUS  || sig == SIGFPE  ||
+	    sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
+	    sig == SIGSYS  || sig == SIGSTKFLT))
+	{
+		printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
+			sig, t->pid, t->uid, t->gid, t->comm);
+	}
+
 	/*
 	 * fast-pathed signals for kernel-internal things like SIGSTOP
 	 * or SIGKILL.

Would turning that into a switch() generate better code.

Doubt it: in the worst case you still nee to check for each possibility. Furthermore a.f.a.i.k. with switch you cannot do 'unlinkely()'.

Folkert van Heusden

Signature · 11 lines

MultiTail er et flexible tool for a kontrolere Logfiles og commandoer.
Med filtrer, farger, sammenforinger, forskeliger ansikter etc.
http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Jan Engelhardt

2007-05-20 20:38 UTC #13 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 15 lines · Folkert van Heusden

Quoted 15 lines

kernel/signal.c line 720

Quoted 13 lines

kernel/signal.c +9 -0

+	if (unlikely(sig == SIGQUIT || sig == SIGILL  || sig == SIGTRAP ||
+	    sig == SIGABRT || sig == SIGBUS  || sig == SIGFPE  ||
+	    sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
+	    sig == SIGSYS  || sig == SIGSTKFLT))
+	{
+		printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
+			sig, t->pid, t->uid, t->gid, t->comm);
+	}
+
 	/*
 	 * fast-pathed signals for kernel-internal things like SIGSTOP
 	 * or SIGKILL.

Would turning that into a switch() generate better code.

Yes, this time.

Quoted 2 lines

Doubt it: in the worst case you still nee to check for each possibility. Furthermore a.f.a.i.k. with switch you cannot do 'unlinkely()'.

With if(), it generates a ton of "CMP, JE" instructions. With switch(), I would assume gcc transforms it into using a jump table (aka "JMP [table+sig]")

I tried it: with switch(), gcc transforms this into a bitmap comparison ("MOV eax, 1; SHL eax, sig; TEST eax, 0x830109f8"), which seems even cheaper than a jump table.

Jan

Signature · 5 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Folkert van Heusden

2007-05-20 20:55 UTC #14 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 19 lines

Quoted 14 lines
Quoted 14 lines
Review
Quoted 13 lines
(quoted diff) +9 -0
+	if (unlikely(sig == SIGQUIT || sig == SIGILL  || sig == SIGTRAP ||
+	    sig == SIGABRT || sig == SIGBUS  || sig == SIGFPE  ||
+	    sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
+	    sig == SIGSYS  || sig == SIGSTKFLT))
+	{
+		printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
+			sig, t->pid, t->uid, t->gid, t->comm);
+	}
+
 	/*
 	 * fast-pathed signals for kernel-internal things like SIGSTOP
 	 * or SIGKILL.
Would turning that into a switch() generate better code.
Yes, this time.
Quoted 2 lines
Doubt it: in the worst case you still nee to check for each possibility. Furthermore a.f.a.i.k. with switch you cannot do 'unlinkely()'.

Quoted 6 lines

With if(), it generates a ton of "CMP, JE" instructions. With switch(), I would assume gcc transforms it into using a jump table (aka "JMP [table+sig]")
I tried it: with switch(), gcc transforms this into a bitmap comparison ("MOV eax, 1; SHL eax, sig; TEST eax, 0x830109f8"), which seems even cheaper than a jump table.

Ok, here's the new patch against 2.6.21.1:

Signed-off by Folkert van Heusden <[email protected]>

signal.c renamed from signal.c.org +19 -0

@@ -739,6 +739,25 @@
 	struct sigqueue * q = NULL;
 	int ret = 0;
 
+	/* emit some logging for nasty signals
+	 * especially SIGSEGV and friends aught to be looked at when happening
+	 */
+	switch(sig) {
+	case SIGQUIT: 
+	case SIGILL: 
+	case SIGTRAP:
+	case SIGABRT: 
+	case SIGBUS: 
+	case SIGFPE:
+	case SIGSEGV: 
+	case SIGXCPU: 
+	case SIGXFSZ:
+	case SIGSYS: 
+	case SIGSTKFLT:
+		printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
+			sig, t -> pid, t -> uid, t -> gid, t -> comm);
+	}
+
 	/*
 	 * fast-pathed signals for kernel-internal things like SIGSTOP
 	 * or SIGKILL.

Folkert van Heusden

Signature · 11 lines

MultiTail e uno flexible tool per seguire di logfiles e effettuazione
di commissioni. Feltrare, provedere da colore, merge, 'diff-view',
etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andi Kleen

2007-05-20 21:14 UTC #15 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

signal.c line 756

Quoted 12 lines

signal.c renamed from signal.c.org +12 -0

+	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 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

Folkert van Heusden

2007-05-20 21:20 UTC #16 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 7 lines

signal.c renamed from signal.c.org +7 -0

+	switch(sig) {
+	case SIGQUIT: 
+	case SIGILL: 
+	case SIGTRAP:
+	case SIGABRT: 
+	case SIGBUS: 
+	case SIGFPE:

Quoted 8 lines

signal.c line 756
Quoted 5 lines
signal.c renamed from signal.c.org +5 -0
+	case SIGSEGV: 
+	case SIGXCPU: 
+	case SIGXFSZ:
+	case SIGSYS: 
+	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.

Use these signals internally? Afaik these are fatal, stopping the process. So using them internally would be a little tricky.

Quoted 1 line

But I think your list is far too long anyways.

So, which ones would you like to have removed then?

Folkert van Heusden

Signature · 11 lines

To MultiTail einai ena polymorfiko ergaleio gia ta logfiles kai tin
eksodo twn entolwn. Prosferei: filtrarisma, xrwmatismo, sygxwneysi,
diaforetikes provoles. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Folkert van Heusden

2007-05-20 21:23 UTC #17 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 14 lines

Quoted 6 lines
Quoted 6 lines
signal.c renamed from signal.c.org +6 -0
+	switch(sig) {
+	case SIGQUIT: 
+	case SIGILL: 
+	case SIGTRAP:
+	case SIGABRT: 
+	case SIGBUS: 
Quoted 8 lines
signal.c line 756
Quoted 6 lines
signal.c renamed from signal.c.org +6 -0
+	case SIGFPE:
+	case SIGSEGV: 
+	case SIGXCPU: 
+	case SIGXFSZ:
+	case SIGSYS: 
+	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.

Quoted 5 lines

Use these signals internally? Afaik these are fatal, stopping the process. So using them internally would be a little tricky.
Quoted 1 line
But I think your list is far too long anyways.
So, which ones would you like to have removed then?

(and why, of course, to enlighten me: some are educated guesses)

Folkert van Heusden

Signature · 11 lines

MultiTail ist eine flexible Applikation um Logfiles und Kommando
Eingaben zu uberprufen. Inkl. Filter, Farben, Zusammenfuhren,
Ansichten etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andi Kleen

2007-05-20 21:27 UTC #18 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

In reply to Folkert van Heusden

Quoted 16 lines · Folkert van Heusden

Quoted 7 lines
Quoted 7 lines
signal.c renamed from signal.c.org +7 -0
+	switch(sig) {
+	case SIGQUIT: 
+	case SIGILL: 
+	case SIGTRAP:
+	case SIGABRT: 
+	case SIGBUS: 
+	case SIGFPE:
Quoted 8 lines
signal.c line 756
Quoted 5 lines
signal.c renamed from signal.c.org +5 -0
+	case SIGSEGV: 
+	case SIGXCPU: 
+	case SIGXFSZ:
+	case SIGSYS: 
+	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.

Quoted 2 lines

Use these signals internally? Afaik these are fatal, stopping the process. So using them internally would be a little tricky.

All of them are catchable.

Quoted 4 lines

Quoted 2 lines
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.

-Andi

Jeff Dike

2007-05-20 22:22 UTC #19 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 6 lines · Andi Kleen

Quoted 3 lines
Quoted 1 line
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 - UML catches these internally and handles them.

Jeff

Gábor Lénárt

2007-05-21 11:46 UTC #20 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

In reply to Folkert van Heusden

Quoted 16 lines · Folkert van Heusden

Quoted 7 lines
Quoted 7 lines
signal.c renamed from signal.c.org +7 -0
+	switch(sig) {
+	case SIGQUIT: 
+	case SIGILL: 
+	case SIGTRAP:
+	case SIGABRT: 
+	case SIGBUS: 
+	case SIGFPE:
Quoted 8 lines
signal.c line 756
Quoted 5 lines
signal.c renamed from signal.c.org +5 -0
+	case SIGSEGV: 
+	case SIGXCPU: 
+	case SIGXFSZ:
+	case SIGSYS: 
+	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.

Quoted 2 lines

Use these signals internally? Afaik these are fatal, stopping the process. So using them internally would be a little tricky.

For example mplayer uses SIGSEGV: it does not check ALL of the possible error situations, in case of SIGSEGV (a bad stream etc) it quickly reinit itself from the last position. It's much better in performance (well sure for a stream without error, or only few of them) than to check all of the possible problems. Nowdays it may not a problem to check everything but it WAS when MPlayer born (much slower CPUs). But some signals are also useful for emulation etc (eg in my own DOS emulator some years ago ....).

Signature · 1 line

- Gábor

Andrea Righi

author

2007-05-21 10:45 UTC #21 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

In reply to Andi Kleen

Quoted 17 lines · Andi Kleen

signal.c line 756
Quoted 12 lines
signal.c renamed from signal.c.org +12 -0
+	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 only unhandled signals should be printed this way because some programs use them internally. But I think your list is far too long anyways.

Quoted 2 lines

-Andi

Maybe you could use somthing similar to unhandled_signal() in arch/x86_64/mm/fault.c, but I agree that the list seems a bit too long...

-Andrea

Folkert van Heusden

2007-05-21 11:04 UTC #22 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 2 lines

Quoted 2 lines
Quoted 2 lines
(quoted diff) +2 -0
+	switch(sig) {
+	case SIGQUIT: 

...

Quoted 8 lines

Quoted 5 lines
Review
Quoted 1 line
(quoted diff) +1 -0
+	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 use somthing similar to unhandled_signal() in arch/x86_64/mm/fault.c, but I agree that the list seems a bit too long...

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.

Signed-off by: Folkert van Heusden <[email protected]>

signal.c renamed from signal.c.org +5 -0

@@ -739,6 +739,8 @@
 	struct sigqueue * q = NULL;
 	int ret = 0;
 
+	/* emit some logging for unhandled signals
+	 */
+	if (sig_fatal(t, sig))
+	{
+		printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",

+ sig, t -> pid, t -> uid, t -> gid, t -> comm);
+ }
+
/*
* fast-pathed signals for kernel-internal things like SIGSTOP
* or SIGKILL.

of course, this can also be limited to only the interesting signals:

Signed-off by: Folkert van Heusden <[email protected]>

signal.c renamed from signal.c.org +22 -0

@@ -739,6 +739,28 @@
 	struct sigqueue * q = NULL;
 	int ret = 0;
 
+	/* emit some logging for nasty signals
+	 * especially SIGSEGV and friends aught to be looked at when happening
+	 */
+	switch(sig) {
+	case SIGQUIT: 
+	case SIGILL: 
+	case SIGTRAP:
+	case SIGABRT: 
+	case SIGBUS: 
+	case SIGFPE:
+	case SIGSEGV: 
+	case SIGXCPU: 
+	case SIGXFSZ:
+	case SIGSYS: 
+	case SIGSTKFLT:
+		if (sig_fatal(t, sig))
+		{
+			printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
+			sig, t -> pid, t -> uid, t -> gid, t -> comm);
+		}
+	}
+
 	/*
 	 * fast-pathed signals for kernel-internal things like SIGSTOP
 	 * or SIGKILL.

Folkert van Heusden

Signature · 11 lines

Multitail - gibkaja utilita po sledovaniju log-fajlov i vyvoda
kommand. Fil'trovanie, raskra?ivanie, slijanie, vizual'noe sravnenie,
i t.d.  http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Jan Engelhardt

2007-05-21 12:30 UTC #23 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

signal.c line 744

Quoted 8 lines · Folkert van Heusden

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.
signal.c renamed from signal.c.org +3 -0
+	/* emit some logging for unhandled signals
+	 */
+	if (sig_fatal(t, sig))

Not unhandled_signal()?

Review

Quoted 1 line

(quoted diff) +1 -0
+	{

if (sig_fatal(t, sig)) {

Review

Quoted 1 line

(quoted diff) +1 -0

+		printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",

s/send/sent/;

signal.c line 760

Quoted 1 line

signal.c renamed from signal.c.org +1 -0
+		sig, t -> pid, t -> uid, t -> gid, t -> comm);

t->pid, t->uid, t->gid, t->comm);

Quoted 32 lines

(quoted diff) +2 -0
+	}
+
/*
* fast-pathed signals for kernel-internal things like SIGSTOP
* or SIGKILL.
of course, this can also be limited to only the interesting signals:
Signed-off by: Folkert van Heusden <[email protected]>
signal.c renamed from signal.c.org +15 -0
@@ -739,6 +739,28 @@
 	struct sigqueue * q = NULL;
 	int ret = 0;
 
+	/* emit some logging for nasty signals
+	 * especially SIGSEGV and friends aught to be looked at when happening
+	 */
+	switch(sig) {
+	case SIGQUIT: 
+	case SIGILL: 
+	case SIGTRAP:
+	case SIGABRT: 
+	case SIGBUS: 
+	case SIGFPE:
+	case SIGSEGV: 
+	case SIGXCPU: 
+	case SIGXFSZ:
+	case SIGSYS: 
+	case SIGSTKFLT:

signal.c line 766

Quoted 10 lines

signal.c renamed from signal.c.org +7 -0

+		if (sig_fatal(t, sig))
+		{
+			printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
+			sig, t -> pid, t -> uid, t -> gid, t -> comm);
+		}
+	}
+
 	/*
 	 * fast-pathed signals for kernel-internal things like SIGSTOP
 	 * or SIGKILL.

Jan

Signature · 5 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Folkert van Heusden

2007-05-21 12:47 UTC #24 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 7 lines

Review
Quoted 6 lines
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.
(quoted diff) +3 -0
+	/* 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.

Quoted 6 lines

Review
Quoted 1 line
(quoted diff) +1 -0
+	{
if (sig_fatal(t, sig)) {
Review
Quoted 1 line
(quoted diff) +1 -0
+		printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
s/send/sent/;
Review
Quoted 1 line
(quoted diff) +1 -0
+		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.

Signed-off by: Folkert van Heusden <[email protected]>

signal.c renamed from signal.c.org +6 -0

@@ -739,6 +739,12 @@
 	struct sigqueue * q = NULL;
 	int ret = 0;
 
+	/* unhandled fatal signals are logged */
+	if (sig_fatal(t, sig)) {
+		printk(KERN_WARNING "Sig %d sent to %d owned by %d.%d (%s)\n",
+		sig, t->pid, t->uid, t->gid, t->comm);
+	}
+
 	/*
 	 * fast-pathed signals for kernel-internal things like SIGSTOP
 	 * or SIGKILL.

Folkert van Heusden

Signature · 11 lines

MultiTail e uno flexible tool per seguire di logfiles e effettuazione
di commissioni. Feltrare, provedere da colore, merge, 'diff-view',
etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andrea Righi

author

2007-05-21 13:58 UTC #25 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 8 lines · Folkert van Heusden

Quoted 7 lines
Review
Quoted 6 lines
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.
(quoted diff) +3 -0
+	/* emit some logging for unhandled signals
+	 */
+	if (sig_fatal(t, sig))
Not unhandled_signal()?

Quoted 4 lines

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.

What about ptrace()'d processes? I don't think we should log signals for them...

-Andrea

Folkert van Heusden

2007-05-21 18:59 UTC #26 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Review
Quoted 6 lines
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.
(quoted diff) +3 -0
+	/* emit some logging for unhandled signals
+	 */
+	if (sig_fatal(t, sig))
Not unhandled_signal()?

Quoted 5 lines

Quoted 4 lines
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.
What about ptrace()'d processes? I don't think we should log signals for them...

Why not?

Folkert van Heusden

Signature · 11 lines

MultiTail es una herramienta flexibele para consiguir archivos de log,
y para ejecutar ordenes. Filtrar, anadir colores, merger y vista de
las differencias.  http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andrea Righi

author

2007-05-21 22:15 UTC #27 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 7 lines · Folkert van Heusden

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Review
Quoted 6 lines
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.
(quoted diff) +3 -0
+	/* emit some logging for unhandled signals
+	 */
+	if (sig_fatal(t, sig))
Not unhandled_signal()?

Quoted 7 lines

Quoted 5 lines
Quoted 4 lines
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.
What about ptrace()'d processes? I don't think we should log signals for them...
Why not?

Maybe sometimes it's useful, maybe not, but I suppose that usually only the controlling process should care about the critical signals received by the controlled process. I simply don't think it should be a system issue. For example I wouldn't like to have a lot of messages in the kernel logs just because I'm debugging some segfaulting programs with gdb.

-Andrea

Satyam Sharma

2007-05-23 18:00 UTC #28 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

In reply to Folkert van Heusden

Quoted 16 lines · Folkert van Heusden

Quoted 7 lines
Review
Quoted 6 lines
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.
(quoted diff) +3 -0
+    /* 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.
Quoted 3 lines
Quoted 1 line
+ {
if (sig_fatal(t, sig)) {
Quoted 1 line
+ printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",

Quoted 8 lines

Quoted 3 lines
s/send/sent/;
Quoted 1 line
+ 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.

Folkert van Heusden

2007-05-23 18:45 UTC #29 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 11 lines

Quoted 8 lines
Quoted 3 lines
Quoted 1 line
+ {
if (sig_fatal(t, sig)) {
Quoted 1 line
+ printk(KERN_WARNING "Sig %d send to %d owned by %d.%d
(%s)\n",
Quoted 3 lines
s/send/sent/;
Quoted 1 line
+ 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, can you please make this KERN_INFO (or lower) instead of KERN_WARNING.

Description:
This patch adds code to the signal-sender making it log a message when an unhandled fatal signal will be delivered.

Signed-of by: Folkert van Heusden <[email protected]

signal.c renamed from signal.c.org +6 -0

@@ -739,6 +739,12 @@
 	struct sigqueue * q = NULL;
 	int ret = 0;
 
+	/* unhandled fatal signals are logged */
+	if (sig_fatal(t, sig)) {
+		printk(KERN_INFO "Sig %d sent to %d owned by %d.%d (%s)\n",
+		sig, t->pid, t->uid, t->gid, t->comm);
+	}
+
 	/*
 	 * fast-pathed signals for kernel-internal things like SIGSTOP
 	 * or SIGKILL.

Folkert van Heusden

Signature · 9 lines

Temperature outside:    21.437500, temperature livingroom: 
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Folkert van Heusden

2007-06-10 19:53 UTC #30 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
+ {
if (sig_fatal(t, sig)) {
Quoted 1 line
+ printk(KERN_WARNING "Sig %d send to %d owned by %d.%d
(%s)\n",
Quoted 2 lines
s/send/sent/;
Quoted 1 line
+ sig, t -> pid, t -> uid, t -> gid, t -> comm);

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
Quoted 1 line
t->pid, t->uid, t->gid, t->comm);
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.
Description:
This patch adds code to the signal-sender making it log a message when an unhandled fatal signal will be delivered.

New version. This one also informs the user about the sende pid/uid of the signal (when applicable).

Signed-of by: Folkert van Heusden <[email protected]

kernel/signal.c renamed from kernel/signal.c.org +12 -0

@@ -739,6 +739,18 @@
 	struct sigqueue * q = NULL;
 	int ret = 0;
 
+	/* unhandled fatal signals are logged */
+	if (sig_fatal(t, sig)) {
+		if (is_si_special(info))
+			printk(KERN_INFO "Sig %d sent to %d owned by %d.%d (%s)\n",
+				sig, t->pid, t->uid, t->gid, t->comm);
+		else
+			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,
+				info -> _sifields._kill._pid,
+				info -> _sifields._kill._uid);
+	}
+
 	/*
 	 * fast-pathed signals for kernel-internal things like SIGSTOP
 	 * or SIGKILL.

Folkert van Heusden

Signature · 9 lines

Feeling generous? -> http://www.vanheusden.com/wishlist.php
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Jiri Kosina

2007-06-10 20:06 UTC #31 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 1 line · Folkert van Heusden

Signed-of by: Folkert van Heusden <[email protected]

This looks broken BTW.

kernel/signal.c line 751

Quoted 4 lines

kernel/signal.c renamed from kernel/signal.c.org +4 -0

+			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,
+				info -> _sifields._kill._pid,
+				info -> _sifields._kill._uid);

Am I the only one whose eyes are hurt by these spaces?

Signature · 7 lines

Jiri Kosina

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Jan Engelhardt

2007-06-10 20:37 UTC #32 lore raw

Re: signals logged / [RFC] log out-of-virtual-memory events

Quoted 4 lines · Jiri Kosina

Quoted 1 line · Folkert van Heusden
Signed-of by: Folkert van Heusden <[email protected]

Quoted 8 lines

This looks broken BTW.
kernel/signal.c line 751
Quoted 4 lines
kernel/signal.c renamed from kernel/signal.c.org +4 -0
+			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,
+				info -> _sifields._kill._pid,
+				info -> _sifields._kill._uid);
Am I the only one whose eyes are hurt by these spaces?

They were discussed before already. And they were fixed up (t->uid...). And now new ones got added. Ergh.

Jan

Signature · 5 lines

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andrea Righi

author

2007-05-18 07:50 UTC #33 lore raw

In reply to Rik van Riel

Quoted 11 lines · Rik van Riel

Quoted 4 lines · Andrea Righi
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 print_fatal_signals?

Anyway, with print-fatal-signals enabled a user could spam syslogd too, simply with a (char *)0 = 0 program, but we could always identify the spam attempts logging the process uid...

In any case, I agree, it should depend on that patch...

What about adding a simple msleep_interruptible(SOME_MSECS) at the end of log_vm_enomem() or, at least, a might_sleep() to limit the potential spam/second rate?

-Andrea

Robin Holt

2007-05-18 09:16 UTC #34 lore raw

Quoted 17 lines · Andrea Righi

Quoted 11 lines · Rik van Riel
Quoted 4 lines · Andrea Righi
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 print_fatal_signals?
Anyway, with print-fatal-signals enabled a user could spam syslogd too, simply with a (char *)0 = 0 program, but we could always identify the spam attempts logging the process uid...

Quoted 5 lines

In any case, I agree, it should depend on that patch...
What about adding a simple msleep_interruptible(SOME_MSECS) at the end of log_vm_enomem() or, at least, a might_sleep() to limit the potential spam/second rate?

An msleep will slow down this process, but do nothing about slowing down the amount of logging. Simply fork a few more processes and all you are doing with msleep is polluting the pid space.

What about a throttling similar to what ia64 does for floating point assist faults (handle_fpu_swa()). There is a thread flag to not log the events at all. It is rate throttled globally, but uses per cpu variables for early exits. This algorithm scaled well to a thousand cpus.

I think this may be a good fit.

Good Luck,
Robin

Andrea Righi

author

2007-05-18 15:55 UTC #35 lore raw

Quoted 18 lines · Robin Holt

Quoted 17 lines · Andrea Righi
Quoted 10 lines · Rik van Riel
Quoted 4 lines · Andrea Righi
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 print_fatal_signals?
Anyway, with print-fatal-signals enabled a user could spam syslogd too, simply with a (char *)0 = 0 program, but we could always identify the spam attempts logging the process uid...
In any case, I agree, it should depend on that patch...

Quoted 8 lines

Quoted 3 lines
What about adding a simple msleep_interruptible(SOME_MSECS) at the end of log_vm_enomem() or, at least, a might_sleep() to limit the potential spam/second rate?
An msleep will slow down this process, but do nothing about slowing down the amount of logging. Simply fork a few more processes and all you are doing with msleep is polluting the pid space.

Very true.

Quoted 5 lines

What about a throttling similar to what ia64 does for floating point assist faults (handle_fpu_swa()). There is a thread flag to not log the events at all. It is rate throttled globally, but uses per cpu variables for early exits. This algorithm scaled well to a thousand cpus.

Actually using printk_ratelimit() should be enough... BTW print_fatal_signals() should use it too.

-Andrea

---

Signed-off-by Andrea Righi <[email protected]>

mm/mmap.c +24 -0

diff -urpN linux-2.6.21/mm/mmap.c linux-2.6.21-vm-log-enomem/mm/mmap.c
@@ -77,6 +77,29 @@ int sysctl_max_map_count __read_mostly =
 atomic_t vm_committed_space = ATOMIC_INIT(0);
 
 /*
+ * Print current process informations when it fails to allocate new virtual
+ * memory.
+ */
+static inline void log_vm_enomem(void)
+{
+	unsigned long total_vm = 0;
+	struct mm_struct *mm;
+
+	if (unlikely(!printk_ratelimit()))
+		return;
+
+	task_lock(current);
+	mm = current->mm;
+	if (mm)
+		total_vm = mm->total_vm;
+	task_unlock(current);
+
+	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);
+}
+
+/*
  * Check that a process has enough memory to allocate a new virtual
  * mapping. 0 means there is enough memory for the allocation to
  * succeed and -ENOMEM implies there is not.

@@ -175,6 +198,7 @@ int __vm_enough_memory(long pages, int c
 		return 0;
 error:
 	vm_unacct_memory(pages);
+	log_vm_enomem();
 
 	return -ENOMEM;
 }

Andrea Righi

author

2007-05-18 16:05 UTC #36 lore raw

Quoted 29 lines · Andrea Righi

Quoted 16 lines · Robin Holt
Quoted 15 lines · Andrea Righi
Quoted 10 lines · Rik van Riel
Quoted 4 lines · Andrea Righi
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 print_fatal_signals?
Anyway, with print-fatal-signals enabled a user could spam syslogd too, simply with a (char *)0 = 0 program, but we could always identify the spam attempts logging the process uid...
Quoted 9 lines
Quoted 5 lines
In any case, I agree, it should depend on that patch...
What about adding a simple msleep_interruptible(SOME_MSECS) at the end of log_vm_enomem() or, at least, a might_sleep() to limit the potential spam/second rate?
An msleep will slow down this process, but do nothing about slowing down the amount of logging. Simply fork a few more processes and all you are doing with msleep is polluting the pid space.
Very true.

Quoted 9 lines

Quoted 5 lines
What about a throttling similar to what ia64 does for floating point assist faults (handle_fpu_swa()). There is a thread flag to not log the events at all. It is rate throttled globally, but uses per cpu variables for early exits. This algorithm scaled well to a thousand cpus.
Actually using printk_ratelimit() should be enough... BTW print_fatal_signals() should use it too.

I mean, something like this...

---

Limit the rate of the printk()s in print_fatal_signal() to avoid potential DoS problems.

Signed-off-by Andrea Righi <[email protected]>

kernel/signal.c +3 -0

diff -urpN linux-2.6.22-rc1-mm1/kernel/signal.c linux-2.6.22-rc1-mm1-limit-print_fatal_signals-rate/kernel/signal.c
@@ -790,6 +790,9 @@ static void print_vmas(void)
 
 static void print_fatal_signal(struct pt_regs *regs, int signr)
 {
+	if (unlikely(!printk_ratelimit()))
+		return;
+
 	printk("%s/%d: potentially unexpected fatal signal %d.\n",
 		current->comm, current->pid, signr);

Bernd Eckenfels

2007-05-18 16:34 UTC #37 lore raw

Quoted 2 lines · 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

Andrea Righi

author

2007-05-19 10:33 UTC #38 lore raw

PATCH 1/2 limit print_fatal_signal() rate (was: [RFC] log out-of-virtual-memory events)

Quoted 8 lines · Bernd Eckenfels

Quoted 2 lines · 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 of print_fatal_signal() to avoid potential denial-of-service attacks.

Signed-off-by Andrea Righi <[email protected]>

kernel/signal.c +4 -1

diff -urpN linux-2.6.22-rc1-mm1/kernel/signal.c linux-2.6.22-rc1-mm1-vm-log-enomem/kernel/signal.c
@@ -790,7 +790,10 @@ static void print_vmas(void)
 
 static void print_fatal_signal(struct pt_regs *regs, int signr)
 {
-	printk("%s/%d: potentially unexpected fatal signal %d.\n",
+	if (unlikely(!printk_ratelimit()))
+		return;
+
+	printk(KERN_WARNING "%s/%d: potentially unexpected fatal signal %d.\n",
 		current->comm, current->pid, signr);
 
 #ifdef __i386__

Andrew Morton

maintainer

2007-05-21 03:31 UTC #39 lore raw

Re: [PATCH 1/2] limit print_fatal_signal() rate (was: [RFC] log out-of-virtual-memory events)

Quoted 24 lines · On Sat, 19 May 2007 12:33:04 +0200 (MEST) Andrea Righi…

Quoted 8 lines · Bernd Eckenfels
Quoted 2 lines · 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 of print_fatal_signal() to avoid potential denial-of-service attacks.
Signed-off-by Andrea Righi <[email protected]>
diff -urpN linux-2.6.22-rc1-mm1/kernel/signal.c linux-2.6.22-rc1-mm1-vm-log-enomem/kernel/signal.c
kernel/signal.c +0 -0
@@ -790,7 +790,10 @@ static void print_vmas(void)
 

kernel/signal.c static void print_vmas(void) · line 799

Quoted 10 lines

kernel/signal.c +4 -1

 static void print_fatal_signal(struct pt_regs *regs, int signr)
 {
-	printk("%s/%d: potentially unexpected fatal signal %d.\n",
+	if (unlikely(!printk_ratelimit()))
+		return;
+
+	printk(KERN_WARNING "%s/%d: potentially unexpected fatal signal %d.\n",
 		current->comm, current->pid, signr);
 
 #ifdef __i386__

Well OK. But vdso-print-fatal-signals.patch is designated not-for-mainline anyway.

I think the DoS which you identify has been available for a very long time on ia64, x86_64 and perhaps others.

Andrea Righi

author

2007-05-21 10:44 UTC #40 lore raw

Re: [PATCH 1/2] limit print_fatal_signal() rate

Quoted 6 lines · Andrew Morton

Well OK. But vdso-print-fatal-signals.patch is designated not-for-mainline anyway.
I think the DoS which you identify has been available for a very long time on ia64, x86_64 and perhaps others.

For the mainline a fix could be the following...

---

Limit the rate of the kernel logging for the segfaults of user applications, to avoid potential message floods or denial-of-service attacks.

Signed-off-by Andrea Righi <[email protected]>

arch/avr32/mm/fault.c +1 -1

diff -urpN linux-2.6.22-rc2/arch/avr32/mm/fault.c linux-2.6.22-rc2-limit-segfaults-printk-rate/arch/avr32/mm/fault.c
@@ -158,7 +158,7 @@ bad_area:
 	up_read(&mm->mmap_sem);
 
 	if (user_mode(regs)) {
-		if (exception_trace)
+		if (exception_trace && printk_ratelimit())
 			printk("%s%s[%d]: segfault at %08lx pc %08lx "
 			       "sp %08lx ecr %lu\n",
 			       is_init(tsk) ? KERN_EMERG : KERN_INFO,

arch/x86_64/mm/fault.c +2 -1

diff -urpN linux-2.6.22-rc2/arch/x86_64/mm/fault.c linux-2.6.22-rc2-limit-segfaults-printk-rate/arch/x86_64/mm/fault.c
@@ -489,7 +489,8 @@ bad_area_nosemaphore:
 		    (address >> 32))
 			return;
 
-		if (exception_trace && unhandled_signal(tsk, SIGSEGV)) {
+		if (exception_trace && unhandled_signal(tsk, SIGSEGV) &&
+		    printk_ratelimit()) {
 			printk(
 		       "%s%s[%d]: segfault at %016lx rip %016lx rsp %016lx error %lx\n",
 					tsk->pid > 1 ? KERN_INFO : KERN_EMERG,

Ingo Molnar

2007-05-24 07:58 UTC #41 lore raw

Re: [PATCH 1/2] limit print_fatal_signal() rate (was: [RFC] log out-of-virtual-memory events)

In reply to Andrew Morton

Quoted 2 lines · Andrew Morton

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 very much a keeper. Hm?

Ingo

Andrew Morton

maintainer

2007-05-24 08:15 UTC #42 lore raw

Re: [PATCH 1/2] limit print_fatal_signal() rate (was: [RFC] log out-of-virtual-memory events)

Quoted 7 lines · On Thu, 24 May 2007 09:58:35 +0200 Ingo Molnar <[email protected]> wrote:

Quoted 2 lines · Andrew Morton
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 because of the DoS thing, but it has a /proc knob and defaults to off, so it should be OK.

Quoted 4 lines

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 very much a keeper. Hm?

Ingo Molnar

2007-05-24 09:55 UTC #43 lore raw

Re: [PATCH 1/2] limit print_fatal_signal() rate (was: [RFC] log out-of-virtual-memory events)

Quoted 8 lines · Andrew Morton

Quoted 6 lines · On Thu, 24 May 2007 09:58:35 +0200 Ingo Molnar <[email protected]> wrote:
Quoted 2 lines · Andrew Morton
Well OK. But vdso-print-fatal-signals.patch is designated not-for-mainline anyway.

Quoted 6 lines

Quoted 1 line
btw., why?
err, because that's what I decided a year ago. I wonder why ;)
Perhaps because of the DoS thing, but it has a /proc knob and defaults to off, so it should be OK.

yeah. There's also a boot option. To address the DoS angle, should i make it optionally printk_ratelimit() perhaps? (although often the messages come in streams and skipping a message can be annoying)

Quoted 5 lines

Quoted 3 lines
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 very much a keeper. Hm?
<promotes it>

thanks :-)

Ingo

Andrew Morton

maintainer

2007-05-24 16:23 UTC #44 lore raw

Re: [PATCH 1/2] limit print_fatal_signal() rate (was: [RFC] log out-of-virtual-memory events)

Quoted 13 lines · On Thu, 24 May 2007 11:55:03 +0200 Ingo Molnar <[email protected]> wrote:

Quoted 10 lines · Andrew Morton
Quoted 7 lines · On Thu, 24 May 2007 09:58:35 +0200 Ingo Molnar <[email protected]> wrote:
Quoted 2 lines · Andrew Morton
Well OK. But vdso-print-fatal-signals.patch is designated not-for-mainline anyway.
btw., why?

Quoted 8 lines

Quoted 4 lines
err, because that's what I decided a year ago. I wonder why ;)
Perhaps because of the DoS thing, but it has a /proc knob and defaults to off, so it should be OK.
yeah. There's also a boot option. To address the DoS angle, should i make it optionally printk_ratelimit() perhaps? (although often the messages come in streams and skipping a message can be annoying)

I don't think so, really. It takes a deliberate act to turn the thing on, after all.

I we _were_ concerned about the logspam then it might be better to make the feature turn itself off after 100 messages, rather than ratelimiting it.

Andrea Righi

author

2007-05-24 08:50 UTC #45 lore raw

Re: [PATCH 1/2] limit print_fatal_signal() rate

In reply to Ingo Molnar

Quoted 9 lines · Ingo Molnar

Quoted 2 lines · Andrew Morton
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 very much a keeper. Hm?

Actually it seems that SIGKILLs are not printed. In get_signal_to_deliver() we have:

[snip]
@@ -1843,6 +1879,8 @@ relock:
* Anything else is fatal, maybe with a core dump. */
current->flags |= PF_SIGNALED;
+ if ((signr != SIGKILL) && print_fatal_signals)
+ print_fatal_signal(regs, signr);
if (sig_kernel_coredump(signr)) {
/*
* If it was able to dump core, this kills all
[snip]

-Andrea

Ingo Molnar

2007-05-24 09:58 UTC #46 lore raw

Re: [PATCH 1/2] limit print_fatal_signal() rate

Review relock: · line 1883

Quoted 10 lines · Andrea Righi

Actually it seems that SIGKILLs are not printed. In get_signal_to_deliver() we have:

[snip]

(quoted diff) +2 -0

@@ -1843,6 +1879,8 @@ relock:
 		 * Anything else is fatal, maybe with a core dump.
 		 */
 		current->flags |= PF_SIGNALED;
+		if ((signr != SIGKILL) && print_fatal_signals)
+			print_fatal_signal(regs, signr);

yeah. Either i implemented that and forgot, or someone else implemented it. :)

Ingo

Ingo Molnar

2007-05-24 09:57 UTC #47 lore raw

Re: [PATCH 1/2] limit print_fatal_signal() rate (was: [RFC] log out-of-virtual-memory events)

In reply to Ingo Molnar

Quoted 1 line · Ingo Molnar

[...] 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 moment.

Ingo

Bernd Eckenfels

2007-05-18 16:36 UTC #48 lore raw

In reply to Andrea Righi

mm/mmap.c int sysctl_max_map_count __read_mostly = · line 99

Quoted 3 lines · In article <[email protected]> you wrote:

mm/mmap.c +3 -0

+       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
"%s/%d process cannot request more virtual memory: total_vm=%lu, uid=%d\n",
current->comm, current->pid, total_vm, current->uid);

Greetings
Bernd

Andrea Righi

author

2007-05-19 10:34 UTC #49 lore raw

PATCH 2/2 log out-of-virtual-memory events (was: [RFC] log out-of-virtual-memory events)

Quoted 11 lines · Bernd Eckenfels

Review
Quoted 3 lines · In article <[email protected]> you wrote:
(quoted diff) +3 -0
+       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
"%s/%d process cannot request more virtual memory: total_vm=%lu, uid=%d\n",
current->comm, current->pid, total_vm, current->uid);

Depends on print_fatal_signals patch.

---

Print informations about userspace processes that fail to allocate new virtual memory.

Signed-off-by Andrea Righi <[email protected]>

mm/mmap.c +28 -0

diff -urpN linux-2.6.22-rc1-mm1/mm/mmap.c linux-2.6.22-rc1-mm1-vm-log-enomem/mm/mmap.c
@@ -77,6 +77,31 @@ int sysctl_overcommit_ratio = 50;	/* def
 int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT;
 atomic_t vm_committed_space = ATOMIC_INIT(0);
 
+extern int print_fatal_signals;
+
+/*
+ * Print current process informations when it fails to allocate new virtual
+ * memory.
+ */
+static inline void log_vm_enomem(void)
+{
+	unsigned long total_vm = 0;
+	struct mm_struct *mm;
+
+	if (unlikely(!printk_ratelimit()))
+		return;
+
+	task_lock(current);
+	mm = current->mm;
+	if (mm)
+		total_vm = mm->total_vm;
+	task_unlock(current);
+
+	printk(KERN_WARNING
+	       "%s/%d process cannot request more virtual memory: total_vm=%lu, uid=%d\n",
+	       current->comm, current->pid, total_vm, current->uid);
+}
+
 /*
  * Check that a process has enough memory to allocate a new virtual
  * mapping. 0 means there is enough memory for the allocation to

@@ -177,6 +202,9 @@ int __vm_enough_memory(long pages, int c
 error:
 	vm_unacct_memory(pages);
 
+	if (print_fatal_signals)
+		log_vm_enomem();
+
 	return -ENOMEM;
 }

Andrew Morton

maintainer

2007-05-21 03:32 UTC #50 lore raw

Re: [PATCH 2/2] log out-of-virtual-memory events (was: [RFC] log out-of-virtual-memory events)

Quoted 2 lines · On Sat, 19 May 2007 12:34:01 +0200 (MEST) Andrea Righi…

Print informations about userspace processes that fail to allocate new virtual memory.

Why is this useful?

Andrea Righi

author

2007-05-21 10:48 UTC #51 lore raw

Quoted 7 lines · Andrew Morton

Quoted 2 lines · On Sat, 19 May 2007 12:34:01 +0200 (MEST) Andrea Righi…
Print informations about userspace processes that fail to allocate new virtual memory.
Why is this useful?

Well... in strict overcommit mode (overcommit_memory=2) this is the only way to track down problems of the (bad-designed) user applications that exit when they receive a -ENOMEM without logging anything... and, anyway, it could be an additional aid in figuring out what is going wrong on inside a system. BTW, I don't think it should be enabled by default, so this is the reason why it should depend on print_fatal_signals patch.

-Andrea

Folkert van Heusden

2007-05-20 00:15 UTC #52 lore raw

In reply to Andrea Righi

Quoted 11 lines

Quoted 7 lines
Quoted 4 lines
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 print_fatal_signals?
Anyway, with print-fatal-signals enabled a user could spam syslogd too, simply with a (char *)0 = 0 program, but we could always identify the spam attempts logging the process uid...

Yeah well it's all captured by syslogd/klogd and written to a file and diskspace is cheap.

Folkert van Heusden

Signature · 9 lines

Feeling generous? -> http://www.vanheusden.com/wishlist.php
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>