public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Manfred Schlaegl <manfred.schlaegl@gmx.at>
To: Peter Hurley <peter@hurleysoftware.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 2/2] tty: Fix lockless tty buffer race
Date: Tue, 06 May 2014 10:00:18 +0200	[thread overview]
Message-ID: <53689692.8050304@gmx.at> (raw)
In-Reply-To: <5363B446.7010101@hurleysoftware.com>

On 2014-05-02 17:05, Peter Hurley wrote:
> On 05/02/2014 10:56 AM, Peter Hurley wrote:
>> Commit 6a20dbd6caa2358716136144bf524331d70b1e03,
>> "tty: Fix race condition between __tty_buffer_request_room and flush_to_ldisc"
>> correctly identifies an unsafe race condition between
>> __tty_buffer_request_room() and flush_to_ldisc(), where the consumer
>> flush_to_ldisc() prematurely advances the head before consuming the
>> last of the data committed. For example:
>>
>>             CPU 0                     |            CPU 1
>> __tty_buffer_request_room            | flush_to_ldisc
>>    ...                                |   ...
>>                                       |   count = head->commit - head->read
>>    n = tty_buffer_alloc()             |
>>    b->commit = b->used                |
>>    b->next = n                        |
>>                                       |   if (!count)                /* T */
>>                                       |     if (head->next == NULL)  /* F */
>>                                       |     buf->head = head->next
>>
>> In this case, buf->head has been advanced but head->commit may have
>> been updated with a new value.
>>
>> Instead of reintroducing an unnecessary lock, fix the race locklessly.
>> Read the commit-next pair in the reverse order of writing, which guarantees
>> the commit value read is the latest value written if the head is
>> advancing.

This is a fine solution! I'll verify this against my previous experimental setup
(3.12.x and 3.12.x-rt25), but I dont't expect any problems.

>>
>> Reported-by: Manfred Schlaegl <manfred.schlaegl@gmx.at>
>> Cc: <stable@vger.kernel.org> # 3.12.x+
> 
> The patch submitted by Manfred notes the commits which introduced the
> race [1], but attributes those commits to the 3.11 cycle. Those commits
> were merged in the 3.12 cycle.

You are right. I'm sorry for this.


Regars,
Manfred

      reply	other threads:[~2014-05-06  8:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1399042572-6533-1-git-send-email-peter@hurleysoftware.com>
2014-05-02 14:56 ` [PATCH 2/2] tty: Fix lockless tty buffer race Peter Hurley
2014-05-02 15:05   ` Peter Hurley
2014-05-06  8:00     ` Manfred Schlaegl [this message]

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=53689692.8050304@gmx.at \
    --to=manfred.schlaegl@gmx.at \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter@hurleysoftware.com \
    --cc=stable@vger.kernel.org \
    /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