All of lore.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:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-02 14:56 [PATCH 1/2] Revert "tty: Fix race condition between __tty_buffer_request_room and flush_to_ldisc" Peter Hurley
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.