Re: [PATCH] tty: fix data race in n_tty_receive_buf_common

[Alan Cox <gnomes@lxorguk.ukuu.org.uk>]

> > What does a full (all CPU) trace of the bug look like and what tty driver
> > are you using when you capture the trace ?  

Which tty driver ? serial/msm_serial.c ?

> We are using tty for console logging,
>      |    tty = 0xFFFFFFFF477AC880 -> (
>      |      magic = 21505,
>      |      kref = (refcount = (counter = 2)),
>      |      dev = 0xFFFFFFFFEDE3DA80,
>      |      driver = 0xFFFFFFFFEDE2A480,
>      |      ops = 0xFFFFFF9F26F7D0D0,
>      |      index = 0,
>      |      ldisc_sem = (count = 1, wait_lock = (raw_lock = (owner = 0, 
> next = 0), magic = 3735899821, own
>      |      termiox = 0x0,
>      |      name = "ttyMSM0",
>      |      pgrp = 0x0,

Ok no what I need to see is a trace of what each CPU is doing at the
point you detect the problem. That way we can see what the path that
races is.

> We have seen this issue on 4.9 and also one thing i have observed, 
> before tty is getting reinit in tty_init_dev(),

When yo stop the DMA is it instantaneous or does it cause a final
interrupt after you return from stop_rx ?

To me it still looks like data is being queued after the port is told to
stop but that's not a certainty.

> there is console service exited before it in all the dumps.
>   35206.969644:   <2> init: Service 'console' (pid 7440) exited with 
> status 130
>   35206.969690:   <2> init: Sending signal 9 to service 'console' (pid 
> 7440) process group...
>   35206.970857:   <2> init: kill(7440, 9) failed: No such process.
> 
> So how can we stop request of receive buff, if we already have tty_port 
> and tty is getting reinitialized in midway like above
> case?

Is the port your console device. If you use a different port as a console
device does the problem go away - that could be a very important detail
as the hangup behaviour for the two is quite different.

Alan