On Thu, Sep 17, 2015 at 11:17 AM, Dmitry Vyukov <[email protected]> wrote: > Race on buffer data happens when newly committed data is > picked up by an old flush work 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 necessary visible to flush_to_ldisc. > > Similar bug happens when tty_schedule_flip commits data. > > Update commit with smp_store_release and read commit with > smp_load_acquire, as it is commit that signals data readiness. > This is orthogonal to the existing synchronization on tty_buffer.next, > which is required to not dismiss a buffer with unconsumed data. > > The data race was found with KernelThreadSanitizer (KTSAN).
Reviewed-by: Peter Hurley <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
