> Sorry for the delayed response, as i was waiting for test results.
> I have uploaded the new patch v1 as per your suggestions and result
> looks good.
Thanks for all the testing. This looks good to me too.
Alan
On 1/6/2018 1:20 PM, Kohli, Gaurav wrote:
On 1/6/2018 2:35 AM, Alan Cox wrote:
On Sat, 6 Jan 2018 01:54:36 +0530
"Kohli, Gaurav" wrote:
Hi Alan,
Sorry correcting the typo here:
+retval = tty_ldisc_lock(tty, 5 * HZ);
+if (retval)
+ goto err_release_lock;
tty->port->itty = tty;
/*
* St
On 1/6/2018 2:35 AM, Alan Cox wrote:
On Sat, 6 Jan 2018 01:54:36 +0530
"Kohli, Gaurav" wrote:
Hi Alan,
Sorry correcting the typo here:
+retval = tty_ldisc_lock(tty, 5 * HZ);
+if (retval)
+ goto err_release_lock;
tty->port->itty = tty;
/*
* Structures all installed ... call the ldis
On Sat, 6 Jan 2018 01:54:36 +0530
"Kohli, Gaurav" wrote:
> Hi Alan,
>
> Sorry correcting the typo here:
> +retval = tty_ldisc_lock(tty, 5 * HZ);
> +if (retval)
> + goto err_release_lock;
> tty->port->itty = tty;
> /*
> * Structures all installed ... call the ldisc open routines.
> * If
HI Alan,
Sorry correcting the typo here:
On 1/6/2018 1:44 AM, Kohli, Gaurav wrote:
Hi Alan,
On 1/5/2018 7:45 PM, Alan Cox wrote:
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
ldi
Hi Alan,
Sorry correcting the typo here:
+retval = tty_ldisc_lock(tty, 5 * HZ);
+if (retval)
+ goto err_release_lock;
tty->port->itty = tty;
/*
* Structures all installed ... call the ldisc open routines.
* If we fail here just call release_tty to clean up. No need
* to decrement the us
Hi Alan,
On 1/5/2018 7:45 PM, Alan Cox wrote:
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, i
> 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
>
On 1/5/2018 7:06 PM, Alan Cox wrote:
On Fri, 5 Jan 2018 13:15:45 +0530
"Kohli, Gaurav" 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
On Fri, 5 Jan 2018 13:15:45 +0530
"Kohli, Gaurav" 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 disc
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 c
On Thu, 4 Jan 2018 19:16:46 +0530
"Kohli, Gaurav" wrote:
> > Which tty driver ? serial/msm_serial.c ?
>
> We are using our internal driver, msm_geni_serial.c
Can you make that code available otherwise it's impossible to see what
the problem might be.
> >
> > Ok no what I need to see is a
Which tty driver ? serial/msm_serial.c ?
We are using our internal driver, msm_geni_serial.c
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.
Below is stack trace running by init in our cas
> > 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 = 0x477AC880 -> (
> | magic = 21505,
> | kref
On Wed, 3 Jan 2018 19:18:52 +0530
Gaurav Kohli wrote:
> There can be a race, if receive_buf call comes before
> tty initialization completes in n_tty_open and tty->disc_data
> may be NULL.
This makes no sense. If the race exists then the check you do isn't good
enough because the ldsic dsta is
There can be a race, if receive_buf call comes before
tty initialization completes in n_tty_open and tty->disc_data
may be NULL.
CPU0cpu1
000|n_tty_receive_buf_common() n_tty_open()
-001|n_tty_receive_buf
16 matches
Mail list logo
