[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3a26e298dc604350b6ecf4e3381009a8@baidu.com>
Date: Mon, 14 Jan 2019 02:51:34 +0000
From: "Li,Rongqing" <lirongqing@...du.com>
To: "Kohli, Gaurav" <gkohli@...eaurora.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"jslaby@...e.com" <jslaby@...e.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"alan@...ux.intel.com" <alan@...ux.intel.com>
Subject: 答复: [PATCH][v2] tty: fix race between flush_to_ldisc and tty_open
> -----邮件原件-----
> 发件人: Kohli, Gaurav [mailto:gkohli@...eaurora.org]
> 发送时间: 2019年1月11日 21:57
> 收件人: Li,Rongqing <lirongqing@...du.com>; linux-kernel@...r.kernel.org;
> jslaby@...e.com; gregkh@...uxfoundation.org; alan@...ux.intel.com
> 主题: Re: [PATCH][v2] tty: fix race between flush_to_ldisc and tty_open
>
> Hi,
>
> it don't seems to be good idea to put lock on one function and unlock in some
> other function. If in future some one has to call tty_init_dev, how he can track
> the unlocking as well of ldisc lock.
>
> Regards
> Gaurav
>
This similar condition has existed for a long time, tty_unlock(tty) must be called in
some other functions who call tty_init_dev, since tty_init_dev hold tty_lock, and does
not release it
so I think it is user responsibility to fully understand tty_init_dev; and I can add some
comments for tty_init_dev if this patch can be acceptable;
or a workaround like below:
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index a42a028a9d4e..2f5ad256b6ad 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -425,7 +425,7 @@ static void flush_to_ldisc(struct work_struct *work)
struct tty_ldisc *disc;
tty = port->itty;
- if (tty == NULL)
+ if (tty == NULL || tty->driver_data == NULL)
return;
disc = tty_ldisc_ref(tty);
thanks
-RongQing
Powered by blists - more mailing lists