Messages in this thread | | | Date | Thu, 5 Mar 2015 17:02:06 -0800 | Subject | Re: Possible lock-less list race in scheduler_ipi() | From | Linus Torvalds <> |
| |
On Thu, Mar 5, 2015 at 3:48 PM, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > > llist_next() is pretty simple: > > static inline struct llist_node *llist_next(struct llist_node *node) > { > return node->next; > } > > It is so simple that I wonder if the compiler would be > within its rights to reorder the load of node->next > after some operations within ttwu_do_activate(), thus > causing corruption of this linked-list due to a > concurrent try_to_wake_up() performed by another core. > > Am I too paranoid about the possible compiler mishaps > there, or are my concerns justified ?
I *think* you are too paranoid, because that would be a major compiler bug anyway - gcc cannot reorder the load against anything that might be changing the value. Which obviously includes calling non-inlined functions.
At least the code generation I see doesn't seem to say that gcc gets this wrong:
... leaq -32(%rbx), %rsi #, p movq (%rbx), %rbx # MEM[(struct llist_node *)__mptr_19].next, __mptr movq %r12, %rdi # tcp_ptr__, call ttwu_do_activate.constprop.85 # ...
that "movq (%rbx), %rbx" is the "llist = llist_next(llist);" thing.
Linus
| |