Split this into 2 separate fixes (mailed separately).
Also dropped some READ/WRITE_ONCE. We would like to commit them as
well for the following reasons:
https://github.com/google/ktsan/wiki/READ_ONCE-and-WRITE_ONCE
What do you think about using READ/WRITE_ONCE for all concurrent
accesses to non-co
On Fri, Sep 4, 2015 at 9:49 PM, Peter Hurley wrote:
> On 09/04/2015 03:37 PM, Dmitry Vyukov wrote:
>> On Fri, Sep 4, 2015 at 9:34 PM, Peter Hurley
>> wrote:
>>> Hi Dmitry,
>>>
>>> On 09/04/2015 03:09 PM, Dmitry Vyukov wrote:
Race on buffer data happens in the following scenario:
__tty_
On 09/04/2015 03:37 PM, Dmitry Vyukov wrote:
> On Fri, Sep 4, 2015 at 9:34 PM, Peter Hurley wrote:
>> Hi Dmitry,
>>
>> On 09/04/2015 03:09 PM, Dmitry Vyukov wrote:
>>> Race on buffer data happens in the following scenario:
>>> __tty_buffer_request_room does a plain write of tail->commit,
>>> no ba
On Fri, Sep 4, 2015 at 9:34 PM, Peter Hurley wrote:
> Hi Dmitry,
>
> On 09/04/2015 03:09 PM, Dmitry Vyukov wrote:
>> Race on buffer data happens in the following scenario:
>> __tty_buffer_request_room does a plain write of tail->commit,
>> no barriers were executed before that.
>> At this point fl
Hi Dmitry,
On 09/04/2015 03:09 PM, Dmitry Vyukov wrote:
> Race on buffer data happens in the following scenario:
> __tty_buffer_request_room does a plain write of tail->commit,
> no barriers were executed before that.
> At this point flush_to_ldisc reads this new value of commit,
> and reads buffe
Race on buffer data happens in the following scenario:
__tty_buffer_request_room does a plain write of tail->commit,
no barriers were executed before that.
At this point flush_to_ldisc reads this new value of commit,
and reads buffer data, no barriers in between.
The committed buffer data is not ne
6 matches
Mail list logo
