LWN.net Logo

Dumb question

Dumb question

Posted Jan 15, 2004 19:47 UTC (Thu) by sjmadsen (guest, #4035)
Parent article: Keeping printk() under control

My guess is that the answer to this question is somewhere in the kernel archives, but I'm too
lazy to go find it.

If printk_ratelimit() tells the caller not to print anything out, why can't the squelch be done in
printk() itself and thus avoid touching code everywhere else?

Yes, critical messages might be missed, but that is solved by always allowing messages at
KERN_ERR (or whatever) through, no matter what. Sure, it can be abused, but
printk_ratelimit() can be ignored, too.


(Log in to post comments)

Dumb question

Posted Jan 16, 2004 16:25 UTC (Fri) by dw (subscriber, #12017) [Link]

I can envisage a few situations in which the kernel should really try as hard as it can to get message to the administrator, for instance, a kernel-mode NULL pointer dereference which is just about to cause the system to hang should definately get printed to the console, regardless of the current ratelimiting in effect.

Here's another example - given a forced rate limiting system, an evil user could do something to cause many thousands of printks, then switch to another terminal and run a kernel exploit as many times as required to guess the correct offsets, etc.

Assuming the failed exploit didn't crash the machine, any messages that it may have caused would have been hidden.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds