Hi Arnout ...
This can be useful information to determine which process was
responsible for the OOM-situation, however the logging is not very
informative if the process is an interpreter used for various tasks.
I agree. Sometimes, we need to see te full cmdline. BTW, I suggest to
create a /proc entry or similar to toggle this behaviour, because not
everytime one would need to see complete cmdline. For example, somebody
might be testing a shiny exploit that somehow trigger OOM. Assuming it
feedback god damn long shellcode as parameter, it would be "amusing" to
see them over and over again in kernel log :)
I took a first stab and would be interested to hear what you think:
http://bzzt.net/~arnouten/oom_informative.patch
I strongly suggest to CC that patch to LKML. IMHO, there is a chance it
could go into -mm
Some questions:
* I took the code for getting the cmdline-string from fs/proc/base.c. Of
course it'd be neater not to copy-paste this code. Should it be moved to
a place where both fs/proc and mm can 'see' it? What would be a suitable
place?
How about include/linux/mm.h? mark the function as non static, put the
declaration in mm.h... maybe that should do it.
* What about the buffer size for the oom_pid_cmdline()-function? Is
there a known upper bound for the length of a commandline?
One thing I see here (I could be wrong). You declare char buffer[1024],
IIRC that means 2 byte * 1024 = 2K, while there "len" could be as big as
PAGE_SIZE (4K in x86 32 bit). Don't you think, it would create stack
overflow? CMIIW.
regards,
Mulyadi
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
