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

[Kohli, Gaurav]

On 1/5/2018 7:06 PM, Alan Cox wrote:
> On Fri, 5 Jan 2018 13:15:45 +0530
> "Kohli, Gaurav" <gkohli@xxxxxxxxxxxxxx> wrote:
>
> > Hi Alan,
> > > > > Can you make that code available otherwise it's impossible to see
> > > > > what the problem might be.
> > >   
> >   Âhttps://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/tty/serial?h=msm-4.9
> >   ÂAs discussed , there not seems a problem as we are getting print
> > request even when port seems to closed.
> >
> >
> > tty_ldisc_lock(tty, 5 * HZ);
> >   Âtty_ldisc_setup(tty);
> >   Âtty_ldisc_unlock(tty)
> >
> > But in above lock, there is a chance when flush_to_ldisc will occur
> > first and acquired a lock in
> > tty_ldisc_ref itself.
> Which is fine.
>
> If the flush_to_ldisc gets there first then it will find there is a NULL
> ldisc and do nothing. When it finishes the tty_init_dev will run and will
> be protected from a further re-entry.
>
> If the init_dev gets there first it will complete the init before the
> flush_to_ldisc is permitted to proceed.
>
> In other words we restore the intended invariant that ldisc's do not get
> entered while their setup routine is running.

But in above case , there we can hit another race, if we have a sequence 
like this
tty_init_dev->alloc_tty_struct -> tty_ldisc_init -> this will initialize 
ldisc ,
but at this moment disc_data is still NULL

And if flush_to_ldisc comes in between, it will take ldisc reference and 
proceeds receive buffer.


Regards
Gaurav


--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.