Received: by 10.223.185.116 with SMTP id b49csp246962wrg; Thu, 22 Feb 2018 21:00:19 -0800 (PST) X-Google-Smtp-Source: AH8x2275Kw0xBBULwmFYOWxvZKekIXVEHpyMIkKLIUcUH7ZHdtZwQAAwdFTQcXsHey1W84eGB6AS X-Received: by 10.99.63.139 with SMTP id m133mr424312pga.174.1519362019464; Thu, 22 Feb 2018 21:00:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519362019; cv=none; d=google.com; s=arc-20160816; b=VNcmuUU2D1WKW5DxazRP+IC7cuqD4BK5fnSpstJRN91KQOgu1JdITeAZAB5wHzqjpw gq58epRipuNY5BC3HBzQttOlGSQXiaiKfl6M9LfSoF1UlkxP9RNlA81jktlLzp0L3tPT /7crFKb1cmiIQiVqEOfcHQ//pNvKQ901qPqeRq0E2tylNOpcGqEN3W3F5lBTOgWdLMWc wxivV5GOAp7wDaAXIii3Q8wUvyCVoMwsa2yQaKNrlXrgIx6hJbdfI0taQHMnjzoAlZ9d kOwtpa0vNe5jA+upVJxQfHFT2fBCLokiMLzhw+EZygsPTqgS/D18ea6r2TVUiGV95hgY iUAA== 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:dkim-signature:arc-authentication-results; bh=Zt23b1WmbpHY2l78qfIx0s/cb1oJUp01uXFuoWkHEzM=; b=f+WIQ+xPsPA41utINoc50kY2dGmprgD0ct4qB1DF3T9e2jxTkjjAdVb/qazZkx7I8q zY3Hm5LKR+Ma/2n8Dex7bcfGk/z2olI6zkohv0m0UZQVausyJDEKzRQylOG/ley+7W3y uF7RSCGhBlx8wxm0Fjv38nHoaVznRVcXgAUi+oGJ1NlS8iLJbFi1OlnkUxSldHdHO9mC 0iapWBiIAfnQeY4iFf8X/AcHtVXnU27dD82EqzLLV/IVLcHtYYhnVJKs1PdYoPt/VCo2 1vXYL19tpshepSRcGkO8oT5F7cyrgRd9SNbvh+aFwly3AUBPXkATHBbz+B1PlpyxSUX4 ELiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=eN2oMLAB; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r15-v6si1268942pli.431.2018.02.22.21.00.04; Thu, 22 Feb 2018 21:00:19 -0800 (PST) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=eN2oMLAB; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751530AbeBWE6w (ORCPT + 99 others); Thu, 22 Feb 2018 23:58:52 -0500 Received: from mail-qk0-f176.google.com ([209.85.220.176]:43710 "EHLO mail-qk0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751296AbeBWE6u (ORCPT ); Thu, 22 Feb 2018 23:58:50 -0500 Received: by mail-qk0-f176.google.com with SMTP id j4so3582060qke.10 for ; Thu, 22 Feb 2018 20:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Zt23b1WmbpHY2l78qfIx0s/cb1oJUp01uXFuoWkHEzM=; b=eN2oMLABmG/IEoE1vGB+stUb5xsxEFCQV878iiekDGRY7xOsyLYaStuTVOZuTJwu4j cflLMJzf4vrLOhzebwbTZgcYxhJ4bHzgf+ZHR1Emn8gPxniy6GvZ0yoXDWG87+NVmeoz bywGnWiBxe9Khd9ZY0jDln4uVVu1e6D+6bPPPOBPfik6UCQn8rcxsbOE9w5fUAZb5Ln7 nklMtGP6hTZD8TsJfzIOHRrxpr0uvORH03M1bQ9EXfDM0gVPRXCrRg4ziv88BCEz788s CsewbGMs79P8soOMTErJjL0NlTQ5tkRd7JKeo0hvAeUNDb3LB3XZUdj0mQN8xI2l/6Ct EK2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Zt23b1WmbpHY2l78qfIx0s/cb1oJUp01uXFuoWkHEzM=; b=WKI5nppfTrKmWVLr7aFHEq6INLLLT9y9Dbi4ANuk81gICiKYKRXj1tyUn9092JHWEZ zOnULIarPux9fKEEzWjSjrFA7ZJLxov+1MlGmeAuB3iCAf1Gwc1R2YC1+mdrYz6HepCL DMR3pJM4JGgfMA5YiuIlsTQ6v8VbMhF4sjwRyNed7spCCFIysWOcpheHUMApu0oPtxwh j/b3AyeZlHqBrTGXz0AJDkeYAenjf6zjRjC0kLDLg8NZkaO9i/AU6aCjxkTrklHslzdj 7kwC4U94Mp3wgPFATgxZzq41ld/Jtz4yKrPghJjIbNwfPWwf/vcvWhUUFkehqyBdeQBg gYwQ== X-Gm-Message-State: APf1xPALj66VlGE0+V18Ya25uMKUAIN2TNglI2O4Tugz6lmuCW5HJeXR pfm8K0563PH5B82qJ+IEqZU= X-Received: by 10.55.125.65 with SMTP id y62mr599682qkc.241.1519361929414; Thu, 22 Feb 2018 20:58:49 -0800 (PST) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com. [66.111.4.227]) by smtp.gmail.com with ESMTPSA id e129sm1046828qkd.79.2018.02.22.20.58.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Feb 2018 20:58:48 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id B664B2141C; Thu, 22 Feb 2018 23:58:47 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 22 Feb 2018 23:58:47 -0500 X-ME-Sender: Received: from localhost (unknown [45.32.128.109]) by mail.messagingengine.com (Postfix) with ESMTPA id 478B77E070; Thu, 22 Feb 2018 23:58:46 -0500 (EST) Date: Fri, 23 Feb 2018 13:02:09 +0800 From: Boqun Feng To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Andrea Parri Subject: Re: [RFC tip/locking/lockdep v5 05/17] lockdep: Extend __bfs() to work with multiple kinds of dependencies Message-ID: <20180223050209.qy46njbj7phvuxqy@tardis> References: <20180222070904.548-1-boqun.feng@gmail.com> <20180222070904.548-6-boqun.feng@gmail.com> <20180222142614.GR25201@hirez.programming.kicks-ass.net> <20180222151210.jwxjchywk4jfecyf@tardis> <20180222153034.GO25181@hirez.programming.kicks-ass.net> <20180222155143.GV25235@hirez.programming.kicks-ass.net> <20180222163120.zhytq7yezny4e7mj@tardis> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v72geli2ovdrwu7e" Content-Disposition: inline In-Reply-To: <20180222163120.zhytq7yezny4e7mj@tardis> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --v72geli2ovdrwu7e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 23, 2018 at 12:31:20AM +0800, Boqun Feng wrote: > On Thu, Feb 22, 2018 at 04:51:43PM +0100, Peter Zijlstra wrote: > > On Thu, Feb 22, 2018 at 04:30:34PM +0100, Peter Zijlstra wrote: > > > On Thu, Feb 22, 2018 at 11:12:10PM +0800, Boqun Feng wrote: > > > > On Thu, Feb 22, 2018 at 03:26:14PM +0100, Peter Zijlstra wrote: > > >=20 > > > > > However, I would suggest: > > > > >=20 > > > > > static inline bool is_xr(u16 dep) > > > > > { > > > > > return !!(dep & (DEP_NR_MASK | DEP_RR_MASK)); > > > > > } > > > > >=20 > > > > > static inline bool is_rx(u16 dep) > > > > > { > > > > > return !!(dep & (DEP_RN_MASK | DEP_RR_MASK)); > > > > > } > > > > >=20 > > > > > /* Skip *R -> R* relations */ > > > > > if (have_xr && is_rx(entry->dep)) > > > > > continue; > > > >=20 > > > > I don't think this works, if we pick a *R for previous entry, and f= or > > > > current entry, we have RR, NN and NR, your approach will skip the > > > > current entry, but actually we can pick NN or NR (of course, in __b= fs(), > > > > we can greedily pick NN, because if NR causes a deadlock, so does N= N). > > >=20 > > > I don't get it, afaict my suggestion is identical. > > >=20 > > > You skip condition: pick_dep() < 0, evaluates to: > > >=20 > > > is_rr && (!NN_MASK && !NR_MASK) :=3D > > > is_rr && (RN_MASK | RR_MASK) > > >=20 > > > Which is exactly what I have. > >=20 > > Ooh, I think I see what I did wrong, would something like: > >=20 > > if (have_xr && !is_nx(entry-dep)) > >=20 > > work? That's a lot harder to argue about though, still much better than >=20 > I think it works. Although I prefer use name "has_nx" for the fucntion. >=20 > > that tri-state pick thing. > >=20 >=20 > Agree. >=20 > > > If that is satisfied, you set entry->is_rr to pick_dep(), which his > > > harder to evaluate, but is something like: > > >=20 > > > is_rr && NR_MASK || !(NN_MASK | RN_MASK) :=3D >=20 > If is_rr is true and NN_MASK is true, pick_dep() will return 0, however, > your expression will return NR_MASK. >=20 It was too late last night, I was meant to say, the correct entry->have_xr should be as follow: > entry->have_xr =3D !(has_nn(entry->dep) || (!is_rr && has_rn(entry->dep)= )); > :=3D !has_nn(entry->dep) && (is_rr || !has_rn(entry->dep)) >=20 so it seems that we have to introduce is_{nn,rn,nx}(), I'm not sure introducing three one-off helpers is a good direction to go. One benefit of using pick_dep() is that we can keep the whole logic in one function. Thoughts? Regards, Boqun > Regards, > Boqun >=20 > > > is_rr && NR_MASK || (NR_MASK | RR_MASK) :=3D > > > (NR_MASK | RR_MASK) > > >=20 > > > (because is_rr && RR_MASK will have been skipped) > > >=20 > > > > >=20 > > > > > entry->have_xr =3D is_xr(entry->dep); > >=20 > > This one I think is still correct though. --v72geli2ovdrwu7e Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEj5IosQTPz8XU1wRHSXnow7UH+rgFAlqPoEQACgkQSXnow7UH +ri2xwf/XC5MtkIhe+ak+TLg07EksxBzXSCdR+CGXd4jjuNDxFTqfzdgQbcQNctA 9gmjaJkUQ6y7SRo74A7bc+fHtkCr9F9wn6nk7b1HnDifXv8xssw0TQzIvq5CJuf1 mYVdtoZFK8vnmH+314hMRKaSszV7BbGeD8gmU5P5TXXH2ynW3ulc4VgMDfphLZm3 2g0ZaBSWxGcfTJ0T+Kp3og+oS8TqbrD+/moBwDOhRG4KIqwJeJwS7IZFEomMvLgF NPOU1wXt2riWIM3qgI9SKgKo6pjgoH+GQlKEjgPXi3X72y7kkNRadrZPp6FVk82l N/KODhrqNH89ekfngnIR9pqg69x28w== =VswF -----END PGP SIGNATURE----- --v72geli2ovdrwu7e--