public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jslaby@suse.cz>
To: "Du, Alek" <alek.du@intel.com>
Cc: Jiri Slaby <jirislaby@gmail.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"Tu, Xiaobing" <xiaobing.tu@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"Zhang, Yanmin" <yanmin.zhang@intel.com>,
	"Zuo, Jiao" <jiao.zuo@intel.com>
Subject: Re: [PATCH] tty: hold lock across tty buffer finding and buffer filling
Date: Fri, 16 Mar 2012 13:03:33 +0100	[thread overview]
Message-ID: <4F632C15.5070902@suse.cz> (raw)
In-Reply-To: <09F19C497AD02E4EA4E14917772649B70FCD3DCC@SHSMSX102.ccr.corp.intel.com>

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

  reply	other threads:[~2012-03-16 12:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-15  2:06 [PATCH] tty: hold lock across tty buffer finding and buffer filling Tu, Xiaobing
2012-03-15 10:08 ` Alan Cox
2012-03-15 10:14   ` Du, Alek
2012-03-15 15:40     ` Alan Cox
2012-03-16  9:43     ` Jiri Slaby
2012-03-16  9:49       ` Du, Alek
2012-03-16  9:57         ` Jiri Slaby
2012-03-16 10:01           ` Du, Alek
2012-03-16 10:04             ` Jiri Slaby
2012-03-16 10:08               ` Du, Alek
2012-03-16 10:22                 ` Jiri Slaby
2012-03-16 11:33                   ` Du, Alek
2012-03-16 12:03                     ` Jiri Slaby [this message]
2012-03-16 13:50                       ` Du, Alek
2012-03-16 20:53                         ` Jiri Slaby
2012-03-17  1:05                           ` Alek Du
2012-03-16 23:07                       ` Alan Cox
2012-03-15 20:26 ` gregkh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F632C15.5070902@suse.cz \
    --to=jslaby@suse.cz \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=alek.du@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jiao.zuo@intel.com \
    --cc=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xiaobing.tu@intel.com \
    --cc=yanmin.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox