[lkml]   [2000]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH #2] console lock grabbed too early in printk...
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)

void b(void)

> 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 --- ---
| | | | / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.105 / U:47.400 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site