Messages in this thread | | | Date | Tue, 4 Feb 2014 22:56:24 +0000 (UTC) | From | Mathieu Desnoyers <> | Subject | Perf user-space ABI sequence lock memory barriers |
| |
Hi,
I'm currently integrating user-space performance counters from Perf into LTTng-UST, and I'm noticing something odd regarding the home-made sequence lock found at:
kernel/events/core.c: perf_event_update_userpage()
++userpg->lock; barrier(); [...] barrier(); ++userpg->lock;
This goes in pair with something like this at user-level:
do { seq = pc->lock; barrier();
idx = pc->index; count = pc->offset; if (idx) count += rdpmc(idx - 1);
barrier(); } while (pc->lock != seq);
As we see, only compiler barrier() are protecting all this. First question, is it possible that the update be performed by a thread running on a different CPU than the thread reading the info in user-space ?
I would be tempted to use a volatile semantic on all reads of the lock field (ACCESS_ONCE()). Secondly, read sequence locks usually use a smp_rmb() at the end of the seqcount_begin(), and at the beginning of the seqcount_retry(). Moreover, this is usually matched by smp_wmb() in write_seqcount begin/end().
Am I missing something special about this lock that makes these barriers unnecessary ?
Thanks,
Mathieu
-- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
| |