From owner-freebsd-hackers@FreeBSD.ORG Thu May 7 10:10:37 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 649DE217 for ; Thu, 7 May 2015 10:10:37 +0000 (UTC) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31AFB1C40 for ; Thu, 7 May 2015 10:10:37 +0000 (UTC) Received: by iget9 with SMTP id t9so8507894ige.1 for ; Thu, 07 May 2015 03:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=76fVYf+iSa1fGXze3TCf2gzwoH1Gb+ecTbPb//zy6uQ=; b=XXB+Lt0zbDAlkKWBk68ScXkMHntOeBt54CmK1M52P3/m6FqINTEYqny6UNSTZGmnkJ yxC+w3Mryljk2Nq9Ss3he5ZzYTIb2UGrWu0nNZUy/hOabZltep7+8q42VQE/hlTcJEFY Y7Nm5HaIILd7w2QmBbAOrBojyQqI2I8b2+AntiCDtDQeUzpHum97I9kJ6Hf0VcF+2Cog 0FZUwlfOyh5ybbP6odWHWCWPeP1nS2peMD8mzodQfjFsd8JI3Xq3sEf/av9nAriIyHXp NMz+lsTrbI9YxGapOzI0IkN2WwPSD2vLL5m8F4Sd3lfqIdl8J/vksEN4ZFqekyZOr5Xo BYXA== MIME-Version: 1.0 X-Received: by 10.50.176.137 with SMTP id ci9mr3452065igc.2.1430993436437; Thu, 07 May 2015 03:10:36 -0700 (PDT) Received: by 10.36.2.203 with HTTP; Thu, 7 May 2015 03:10:36 -0700 (PDT) Date: Thu, 7 May 2015 18:10:36 +0800 Message-ID: Subject: Memory barriers about buf_ring(9) From: rhenjau To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 10:10:37 -0000 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); } -- -rhenjau