Chris Lattner writes:
> 6. Poor judgement and placement of printk's can lead to recursive
> printk's.
With the stock kernel and the non-user pointer rule, the only way to
cause this is to put a printk in either printk itself, or the console
print function. In this case, no amount of changes to the locking will
fix this. In fact, trying to fix it makes it far worse.
> 5. As such, a kernel developer may not invest as much thought into printk
> placement as, say, a new buffer cache design.
With what I've said above, the kernel developer would have to be very
dumb to put a printk in those places. It's almost on the level of doing:
void a(void)
{
b();
}
void b(void)
{
a();
}
> Personally, I don't care which one is used, I just don't want to get
> burned again in the future.
The rules:
1. Don't pass user addresses to printk
2. Don't call printk from the low-level console print routes
If this rules are followed, you will not get burned.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King rmk@arm.linux.org.uk --- ---
| | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:14 EST