From owner-freebsd-hackers@FreeBSD.ORG Thu May 7 15:56:00 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3EE7910 for ; Thu, 7 May 2015 15:56:00 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i373.relay.mailchannels.net [174.136.5.175]) by mx1.freebsd.org (Postfix) with ESMTP id E8EE5186E for ; Thu, 7 May 2015 15:55:59 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp3.ore.mailhop.org (ip-10-237-13-110.us-west-2.compute.internal [10.237.13.110]) by relay.mailchannels.net (Postfix) with ESMTPA id C6835100D27; Thu, 7 May 2015 14:21:10 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp3.ore.mailhop.org (smtp3.ore.mailhop.org [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Thu, 07 May 2015 14:21:11 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1431008470897:1445727720 X-MC-Ingress-Time: 1431008470897 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp3.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YqMfj-00057K-Tr; Thu, 07 May 2015 14:21:08 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t47EKwN5067109; Thu, 7 May 2015 08:20:58 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX19Z8ChjxjuHSObIgUeEbp8n Message-ID: <1431008458.6170.165.camel@freebsd.org> Subject: Re: Memory barriers about buf_ring(9) From: Ian Lepore To: rhenjau Cc: freebsd-hackers@freebsd.org Date: Thu, 07 May 2015 08:20:58 -0600 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 15:56:00 -0000 On Thu, 2015-05-07 at 18:10 +0800, rhenjau wrote: > Hi, hackers > I'm reading buf_ring(9) and have a question about the following > function. Is a memory barrier needed before br_cons_tail to prevent the > loading of br_ring[cons_head] load is reordered after br_cons_tail is set? > Producers may overwrite the area. > > /* > * single-consumer dequeue > * use where dequeue is protected by a lock > * e.g. a network driver's tx queue lock > */ > static __inline void * > buf_ring_dequeue_sc(struct buf_ring *br) > { > uint32_t cons_head, cons_next; > #ifdef PREFETCH_DEFINED > uint32_t cons_next_next; > #endif > uint32_t prod_tail; > void *buf; > > cons_head = br->br_cons_head; > prod_tail = br->br_prod_tail; > > cons_next = (cons_head + 1) & br->br_cons_mask; > #ifdef PREFETCH_DEFINED > cons_next_next = (cons_head + 2) & br->br_cons_mask; > #endif > > if (cons_head == prod_tail) > return (NULL); > > #ifdef PREFETCH_DEFINED > if (cons_next != prod_tail) { > prefetch(br->br_ring[cons_next]); > if (cons_next_next != prod_tail) > prefetch(br->br_ring[cons_next_next]); > } > #endif > br->br_cons_head = cons_next; > buf = br->br_ring[cons_head]; > > #ifdef DEBUG_BUFRING > br->br_ring[cons_head] = NULL; > if (!mtx_owned(br->br_lock)) > panic("lock not held on single consumer dequeue"); > if (br->br_cons_tail != cons_head) > panic("inconsistent list cons_tail=%d cons_head=%d", > br->br_cons_tail, cons_head); > #endif > ----------------------------------------------------- need memory > barrier? > br->br_cons_tail = cons_next; > return (buf); > } > There was some discussion and changes relating to barriers in buf_ring, but it looks like the changes never got committed (I don't know why). https://reviews.freebsd.org/D1945 -- Ian