Re: [uml-user] obtaining debugging output

[BlaisorBlade <bla...@ya...>]

On Wednesday 13 October 2004 01:33, Jeff Dike wrote:
> u32...@an... said:
> > Is there a way in uml of getting printk to output to somewhere  on the
> > network, a serial line, or even a file on the host file system?
>
> printk output should be sent out as soon as it happens.  If you think
> there's stuff stuck in the printk buffer, then attach gdb to UML and
> 'printf "%s", log_buf'.
>
> 				Jeff

Sorry Jeff, I did not finish to study this, but it seems that ttys are not 
flushed on close, both from the code I see and from certain behaviour.

The problem is in arch/um/drivers/line.c: why is flush_buffer called only by 
line_write and line_write_interrupt and not also by line_close? Have you a 
good explaination of why this is good?

In fact, when UML crashes, a lot of times the stack-trace is not output (I 
know there could be other reasons, but this seems the right one).

If you agree with me this must be fixed, we have to be careful, to avoid 
racing with line_write and line_write_interrupt. Or better, avoiding the race 
is difficult because the current locking is completely broken.

In fact, line_write_interrupt is racy and using a semaphore for the locking is 
broken. In fact, using a semaphore means that no locking is possible from the 
interrupt. In fact you are not doing any locking there. But the interrupt 
could be interrupting the normal accessors, or they could be running on other 
processors (and let's not speak about the interrupt preemptibility patches 
floating around, which make even more interrupts situation SMP-like).

Start from this page about the kind of locking that must be used in various 
contexts:

http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/c214.html#MINIMUM-LOCK-REQIREMENTS

And yes, I saw the local_irq_save in line_write, and no, it is not enough, 
because you could be reading inconsistent data.

And however the second part is lockless - maybe it's ok, but without lock 
usage specifications in the source I would not try to do lockless work on a 
struct line; even if it's correct, someone could guess "Here we are under 
lock" and be wrong.

We could maybe be lazy on this check:

        if(line->head != line->tail){

I think it's ok, because a missed buffer_data call means we do it next time, 
but I'm not sure if missing a check can result in buffer overrun. And one 
more call is no problem.

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729