* [PATCH] ptr_ring: document usage around __ptr_ring_peek
@ 2018-01-10 14:03 Michael S. Tsirkin
2018-01-10 18:15 ` John Fastabend
2018-01-15 18:19 ` David Miller
0 siblings, 2 replies; 3+ messages in thread
From: Michael S. Tsirkin @ 2018-01-10 14:03 UTC (permalink / raw)
To: linux-kernel, John Fastabend
Cc: David Miller, jakub.kicinski, xiyou.wangcong, jiri, netdev, Jason Wang
This explains why is the net usage of __ptr_ring_peek
actually ok without locks.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
John - I think this is more or less what you meant. Is that right?
include/linux/ptr_ring.h | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 6866df4..d72b2e7 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -174,6 +174,15 @@ static inline int ptr_ring_produce_bh(struct ptr_ring *r, void *ptr)
* if they dereference the pointer - see e.g. PTR_RING_PEEK_CALL.
* If ring is never resized, and if the pointer is merely
* tested, there's no need to take the lock - see e.g. __ptr_ring_empty.
+ * However, if called outside the lock, and if some other CPU
+ * consumes ring entries at the same time, the value returned
+ * is not guaranteed to be correct.
+ * In this case - to avoid incorrectly detecting the ring
+ * as empty - the CPU consuming the ring entries is responsible
+ * for either consuming all ring entries until the ring is empty,
+ * or synchronizing with some other CPU and causing it to
+ * execute __ptr_ring_peek and/or consume the ring enteries
+ * after the synchronization point.
*/
static inline void *__ptr_ring_peek(struct ptr_ring *r)
{
@@ -182,10 +191,7 @@ static inline void *__ptr_ring_peek(struct ptr_ring *r)
return NULL;
}
-/* Note: callers invoking this in a loop must use a compiler barrier,
- * for example cpu_relax(). Callers must take consumer_lock
- * if the ring is ever resized - see e.g. ptr_ring_empty.
- */
+/* See __ptr_ring_peek above for locking rules. */
static inline bool __ptr_ring_empty(struct ptr_ring *r)
{
return !__ptr_ring_peek(r);
--
MST
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] ptr_ring: document usage around __ptr_ring_peek
2018-01-10 14:03 [PATCH] ptr_ring: document usage around __ptr_ring_peek Michael S. Tsirkin
@ 2018-01-10 18:15 ` John Fastabend
2018-01-15 18:19 ` David Miller
1 sibling, 0 replies; 3+ messages in thread
From: John Fastabend @ 2018-01-10 18:15 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel
Cc: David Miller, jakub.kicinski, xiyou.wangcong, jiri, netdev, Jason Wang
On 01/10/2018 06:03 AM, Michael S. Tsirkin wrote:
> This explains why is the net usage of __ptr_ring_peek
> actually ok without locks.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> John - I think this is more or less what you meant. Is that right?
Yep, thanks for following up.
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] ptr_ring: document usage around __ptr_ring_peek
2018-01-10 14:03 [PATCH] ptr_ring: document usage around __ptr_ring_peek Michael S. Tsirkin
2018-01-10 18:15 ` John Fastabend
@ 2018-01-15 18:19 ` David Miller
1 sibling, 0 replies; 3+ messages in thread
From: David Miller @ 2018-01-15 18:19 UTC (permalink / raw)
To: mst
Cc: linux-kernel, john.fastabend, jakub.kicinski, xiyou.wangcong,
jiri, netdev, jasowang
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Wed, 10 Jan 2018 16:03:05 +0200
> This explains why is the net usage of __ptr_ring_peek
> actually ok without locks.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied, thanks Michael.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-01-15 18:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-10 14:03 [PATCH] ptr_ring: document usage around __ptr_ring_peek Michael S. Tsirkin
2018-01-10 18:15 ` John Fastabend
2018-01-15 18:19 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).