On Wed, 5 Oct 2016, Benjamin Tissoires wrote: > > @@ -98,7 +99,9 @@ static ssize_t hidraw_read(struct file *file, char __user *buffer, size_t count, > > > > kfree(list->buffer[list->tail].value); > > list->buffer[list->tail].value = NULL; > > + smp_wmb(); > > list->tail = (list->tail + 1) & (HIDRAW_BUFFER_SIZE - 1); > > + smp_wmb(); > > How does these barriers be needed? To me, list->tail gets accessed just > before, so I doubt the compiler would decide to reorder the code without > changing the semantic. These are CPU barriers, not compiler barriers. (that's just a clarification, it doesn't imply in any way that I'd think the barriers are correct :) ). Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
