Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp3397594imc; Wed, 13 Mar 2019 17:31:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqxfxxWsJX3zjMe34CYWz8YTIc1PEoScTHCy3I/ogV1myBSL03nS65bemAz9yPvHF1EwEQux X-Received: by 2002:a62:568e:: with SMTP id h14mr48401337pfj.134.1552523479347; Wed, 13 Mar 2019 17:31:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552523479; cv=none; d=google.com; s=arc-20160816; b=QWzxnyi5YhtVJ9zniqg/wnTLJjN4iFjYszLH+iFEm3X9cOyXUcXKEURJa3+H0xlWA/ D3d6eniV2d6eI4A4fbw7xziVKYQgEeqTBS4i1VR7azVQUSjTm9UEFJbaIjJF5xAGLQat LOTbz9L3ht3OPeP1mHPtyya4CRjM6rV+bXXQCqvgNCYzuteAh4Kcm27MJ8XauLGT0RL4 RLBJcWvxshr5HvRG6P5roWrtm3HuTKMp308wHPizfMXWEx6rvLd3s6N1tdggnJzD6yqk eBj2hQwsodd8Sw50On0JFK92Ntoa78CdpT0X6zDgOo+CQVUQ8p9E8KyRo92b/gdmZUx5 +9lA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=/LgV6okZLdaDkmm6M9MNzlgNkZEhSeye1eTMhecsqtQ=; b=R5AjcF74O6/R5YNs7p5gKh+SxR/6m79U5Qy8FpCItL/590k11sHxWCnymhzj2MvnDz 4NGcU6ICASRY6nVau858noUCEIgzAe/YiEbWBdnu6d8K1xafdMa2FCQbxAht2j/oiFcj QWnVxM6yotfPOtvBIm6H8jsIcRviAmrze8SdQnUI95xm0dob46gm4br8ugZEnTGrrOAA 9E4D/06WgrnkniG760K6WnMu/EneCZinxmArmEJUazgLFumpOd5Zw9gbvHOTs2GilcAk IuUsCIEELfZgJROlU9sg29GmRIj1/W3HoXfXLKvysVUl5SHs/d+aPSaTDIJbIhdynPAC azIQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x3si5942413plv.424.2019.03.13.17.31.02; Wed, 13 Mar 2019 17:31:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727000AbfCNAac (ORCPT + 99 others); Wed, 13 Mar 2019 20:30:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42650 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726477AbfCNAab (ORCPT ); Wed, 13 Mar 2019 20:30:31 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 90D0030922E8; Thu, 14 Mar 2019 00:30:31 +0000 (UTC) Received: from localhost (unknown [10.18.25.174]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D2FD217CED; Thu, 14 Mar 2019 00:30:28 +0000 (UTC) Date: Wed, 13 Mar 2019 20:30:28 -0400 From: Mike Snitzer To: "Paul E. McKenney" , Nikos Tsironis Cc: hch@infradead.org, agk@redhat.com, dm-devel@redhat.com, mpatocka@redhat.com, iliastsi@arrikto.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] list_bl: Add hlist_bl_add_before/behind helpers Message-ID: <20190314003027.GE4202@redhat.com> References: <20181220180651.4879-1-ntsironis@arrikto.com> <20181220180651.4879-2-ntsironis@arrikto.com> <20190228213201.GB23527@redhat.com> <20190313234853.GA7797@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190313234853.GA7797@linux.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Thu, 14 Mar 2019 00:30:31 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 13 2019 at 7:48pm -0400, Paul E. McKenney wrote: > On Thu, Feb 28, 2019 at 04:32:02PM -0500, Mike Snitzer wrote: > > On Thu, Dec 20 2018 at 1:06pm -0500, > > Nikos Tsironis wrote: > > > > > Add hlist_bl_add_before/behind helpers to add an element before/after an > > > existing element in a bl_list. > > > > > > Signed-off-by: Nikos Tsironis > > > Signed-off-by: Ilias Tsitsimpis > > > --- > > > include/linux/list_bl.h | 27 +++++++++++++++++++++++++++ > > > 1 file changed, 27 insertions(+) > > > > > > diff --git a/include/linux/list_bl.h b/include/linux/list_bl.h > > > index 3fc2cc57ba1b..2fd918e5fd48 100644 > > > --- a/include/linux/list_bl.h > > > +++ b/include/linux/list_bl.h > > > @@ -86,6 +86,33 @@ static inline void hlist_bl_add_head(struct hlist_bl_node *n, > > > hlist_bl_set_first(h, n); > > > } > > > > > > +static inline void hlist_bl_add_before(struct hlist_bl_node *n, > > > + struct hlist_bl_node *next) > > > +{ > > > + struct hlist_bl_node **pprev = next->pprev; > > > + > > > + n->pprev = pprev; > > > + n->next = next; > > > + next->pprev = &n->next; > > > + > > > + /* pprev may be `first`, so be careful not to lose the lock bit */ > > > + WRITE_ONCE(*pprev, > > > + (struct hlist_bl_node *) > > > + ((unsigned long)n | > > > + ((unsigned long)*pprev & LIST_BL_LOCKMASK))); > > A nit, but use of uintptr_t shrinks things a bit: > > + (struct hlist_bl_node *) > + ((uintptr_t)n | ((uintptr_t)*pprev & LIST_BL_LOCKMASK))); > > I am not too concerned about this, though. I'm fine with folding in your suggestion. > The WRITE_ONCE() is to handle races with hlist_bl_empty() (which does contain > the corresponding READ_ONCE()) correct? Correct. > > > +} > > > + > > > +static inline void hlist_bl_add_behind(struct hlist_bl_node *n, > > > + struct hlist_bl_node *prev) > > > +{ > > > + n->next = prev->next; > > > + n->pprev = &prev->next; > > > + WRITE_ONCE(prev->next, n); > > I don't see what this WRITE_ONCE() is interacting with. The traversals > use plain C-language reads, and hlist_bl_empty() can't get here. All > uses of hlist_bl_for_each_entry() invoke hlist_bl_lock() before starting > the traversal, and hlist_bl_for_each_entry_safe() looks to be unused. > (Perhaps it should be removed? Or is there some anticipated use?) > > I don't believe that the WRITE_ONCE() is needed. What am I missing? > > Other than that, looks good. > > Thanx, Paul > I'd imagine it was just born out of symmetry with hlist_bl_add_before() and/or caution. But let's see what Nikos has to say. Thanks, Mike