Messages in this thread |  | | Date | Thu, 25 Oct 2001 10:23:12 -0700 | From | Andrew Morton <> | Subject | Re: Linux 2.4.10: printk() deadlocks |
| |
R.Oehler@GDImbH.com wrote: > > Hi, andrew, > > currently I'm porting our WORM filesystem (OWFS) from kernel > 2.4.0 to kernel 2.4.10. I'm used to rely on printk() to be callable > from every place in the kernel, but now I experience deadlocks > when calling it from some places within our filesystem. > (I'm writing a ~600 lines in 2 seconds and I enlarged the buffer size > to 1MB, what worked perfectly in the past.) > The call-chain is: > ...
But it isn't deadlocked. The EIP points at this statement
spin_unlock_irqrestore(&logbuf_lock, flags); --> console_may_schedule = 0; release_console_sem();
in printk(). So the output is about to come out to the console device(s).
> A diff between printk.c of the two kernels shows: > * Rewrote bits to get rid of console_lock > * 01Mar01 Andrew Morton <andrewm@uow.edu.au> > > Please could you tell me a workaround or some possibility to get out > of this situation? I think printk() should be an absolutely reliable > function which never schedules.
printk() doesn't schedule. However, userspace processes which write to /dev/ttyX *do* schedule, and the two paths use the same code and have to lock against each other, etc. That's why it's all rather unclear.
Sorry, but I think you must be doing something strange to make this happen - can you please diagnose a little further? Investigate further with kdb? Can you send me the wherewithals to reproduce it? Are you running SMP?
- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |