[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F632C15.5070902@suse.cz>
Date: Fri, 16 Mar 2012 13:03:33 +0100
From: Jiri Slaby <jslaby@...e.cz>
To: "Du, Alek" <alek.du@...el.com>
CC: Jiri Slaby <jirislaby@...il.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
"Tu, Xiaobing" <xiaobing.tu@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"Zhang, Yanmin" <yanmin.zhang@...el.com>,
"Zuo, Jiao" <jiao.zuo@...el.com>
Subject: Re: [PATCH] tty: hold lock across tty buffer finding and buffer filling
On 03/16/2012 12:33 PM, Du, Alek wrote:
> Isn't this the nature of "flush" ? If the driver is trying to insert chars to tty buffer, while the app is going to flush the buffer, or shutdown the port,
> that's quite nature that those data gone. Why should I care ?
>
> Sorry, you missed the point of this patch.
No, you do not follow what I am writing.
1) Your driver is broken.
2) Your patch does not solve the problem universally.
ad 1) Use tty refcounting and you won't need to care about buf.tail
being NULL due to shutdown. As an added value, you will fix the other
races too.
ad 2) With your patch, drivers which use tty_prepare_flip_string are
given a tty buffer (chars parameter) which may be *freed* (not flushed,
_freed_) at any time by ioctl flush after the function returns. I.e. the
relocking is hopeless in that case. It only helps drivers which use
tty_insert_flip_string*.
I don't know right now what could be a real cure for point 2). Maybe
RCU. Maybe leaving the lock locked in tty_prepare_flip_string and
introducing tty_finish_flip_string containing an unlock. To be called
right after memcpy_fromio or alike in the drivers.
Or maybe even removing that interface completely...
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists