READ_ONCE_CTRL

3 views
Skip to first unread message

Dmitry Vyukov

unread,
Sep 3, 2015, 5:30:57 AM9/3/15
to kt...@googlegroups.com, Andrey Konovalov
FYI, there is now also READ_ONCE_CTRL:
http://lxr.free-electrons.com/source/include/linux/compiler.h#L258

It is a relaxed load with control-dependency barrier. Since we don't
understand control depenencies, we need to annotate it as
load-acquire.

Andrey, I remember we've hit such case (tsan did not understand
control dependency ordering) and you inserted rmb specifically for
tsan (I've asked you to put it under ifdef and add a comment). We
should start changing such places to use READ_ONCE_CTRL, then we don't
need to insert any tsan-only code.

Andrey Konovalov

unread,
Sep 3, 2015, 7:46:30 AM9/3/15
to Dmitry Vyukov, kt...@googlegroups.com
On Thu, Sep 3, 2015 at 11:30 AM, 'Dmitry Vyukov' via ktsan
<kt...@googlegroups.com> wrote:
> FYI, there is now also READ_ONCE_CTRL:
> http://lxr.free-electrons.com/source/include/linux/compiler.h#L258
>
> It is a relaxed load with control-dependency barrier. Since we don't
> understand control depenencies, we need to annotate it as
> load-acquire.

OK.

> Andrey, I remember we've hit such case (tsan did not understand
> control dependency ordering) and you inserted rmb specifically for
> tsan (I've asked you to put it under ifdef and add a comment). We
> should start changing such places to use READ_ONCE_CTRL, then we don't
> need to insert any tsan-only code.

Yes, this is how we annotated that:

245 if ((atomic_read(&pid->count) == 1) ||
246 atomic_dec_and_test(&pid->count)) {
247 #ifndef CONFIG_KTSAN
248 /* Turn atomic_read into load acquire since ktsan
249 doesn't understand control dependency. */
250 rmb();
251 #endif /* CONFIG_KTSAN */
252 kmem_cache_free(ns->pid_cachep, pid);
253 put_pid_ns(ns);
254 }
255 }

I'm not sure how to fit READ_ONCE_CTRL in here, since the type is atomic_t.

Dmitry Vyukov

unread,
Sep 4, 2015, 1:41:52 PM9/4/15
to Andrey Konovalov, kt...@googlegroups.com
On second thought, it can break only if compiler/processor does write
speculation. Kernel MM declares that it cannot happen.
So let's leave this code as is.



--
Dmitry Vyukov, Software Engineer, dvy...@google.com
Google Germany GmbH, Dienerstraße 12, 80331, München
Geschäftsführer: Graham Law, Christine Elizabeth Flores
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat
sind, leiten Sie diese bitte nicht weiter, informieren Sie den
Absender und löschen Sie die E-Mail und alle Anhänge. Vielen Dank.
This e-mail is confidential. If you are not the right addressee please
do not forward it, please inform the sender, and please erase this
e-mail including any attachments. Thanks.
Reply all
Reply to author
Forward
0 new messages