Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4432194yba; Tue, 9 Apr 2019 19:30:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqxA1Hf12rGioVkQIlWYxvVG9wGVWtoP9kSAqQaWR/fICcGXaCrUHN+IFvEekIbcJcdZVZA7 X-Received: by 2002:a17:902:2a03:: with SMTP id i3mr41232534plb.229.1554863455926; Tue, 09 Apr 2019 19:30:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554863455; cv=none; d=google.com; s=arc-20160816; b=GsDMFWwRTjn0m+pDnGvNm+i4fGJd9sir3TIRpXjryl7hVF5ZwuJUjvNLHZe+jX8pNv fa4GSyiz3ygTXKf+gIZgIU3vxyds4muvZ4QA+BVtM/XKI8Qo6AFXZuJKHhCsGA7OGBTV K6toydtJIu6sfqL/FsX6OkXkNAI4gd2+pztr0g/mh7DEb4LRygCuXNQG3GzAICnW4A9x EwgbhgG8ysVs/pUJm/0zfsC+KugEOI2zI1IDmFvn2J+kSke+mQTTiQ6ezmR3MK17poH6 pQmgkv1ruwZmnlqxadhSUxpdpGm/5yjfiLE20Kngt7STTClCi51ofnqF0Zrnmr4PAD4D xYaA== 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; bh=oHTxmM5fwiFMkVGqyhoDNn94NaKuJbhVDB+sW7BxeqU=; b=cmD2T6d/98542Kng1eyeOsIxQfw9/xXMMvtPd7gBPdio3IUYZ4VpFuBzDLpQqpjYgq 5i/5hiEY+dB6MSUTPF21ixMwugDXwWZG60ikaE6ZMkZxsAj4HUtqFhpR2aj7CTX+QtBx jzmOnLJzeio5+lObahEJEu2jG2shXAzdt+tR2I9Q9wzLkA07uzLoXFCY7Gsjsxu1ZOgG W3kZyBFRvIZDU09x1IOOM4LSpvyZIIXBCt11v0LBkFYSpxegpIazlVO45is/FWQDevGX vIeGOrJBm+zpPQImcxSZOSdDKjRmLd1K38waxLBw73HgcrJjuhoSM5fuf6W30+VrC0Re TNCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=2tFi6VbJ; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j64si7209976pgd.537.2019.04.09.19.30.40; Tue, 09 Apr 2019 19:30:55 -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; dkim=pass header.i=@kernel.org header.s=default header.b=2tFi6VbJ; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726784AbfDJC2w (ORCPT + 99 others); Tue, 9 Apr 2019 22:28:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:49512 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726513AbfDJC2w (ORCPT ); Tue, 9 Apr 2019 22:28:52 -0400 Received: from localhost (lfbn-1-18355-218.w90-101.abo.wanadoo.fr [90.101.143.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9CDCE2084F; Wed, 10 Apr 2019 02:28:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554863331; bh=whT/QhC4HHKekpkPzhuf92P1WlwCH4Fbqnn8pZR1tag=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=2tFi6VbJsjQwyBW+ULM3u2qj7eHXAjltW2uJou/WN4npJBVwofBI7vo7rYypXcIKE UVRUBKZT66/uy5hkrOtuLHyP9BFZj4ETBxtvI5TMWSnE3wgDkYUK2bAngXk8vsWpB8 Geyo66LZwUqQiTIfCDLM1qGdv5kBxV+sHfW3GxD4= Date: Wed, 10 Apr 2019 04:28:48 +0200 From: Frederic Weisbecker To: Peter Zijlstra Cc: LKML , Ingo Molnar Subject: Re: [PATCH 4/4] locking/lockdep: Test all incompatible scenario at once in check_irq_usage() Message-ID: <20190410022846.GA30602@lenoir> References: <20190402160244.32434-1-frederic@kernel.org> <20190402160244.32434-5-frederic@kernel.org> <20190409130352.GV4038@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190409130352.GV4038@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 09, 2019 at 03:03:52PM +0200, Peter Zijlstra wrote: > On Tue, Apr 02, 2019 at 06:02:44PM +0200, Frederic Weisbecker wrote: > > @@ -1988,45 +1961,151 @@ static int exclusive_bit(int new_bit) > > return state | (dir ^ LOCK_USAGE_DIR_MASK); > > } > > > > +static unsigned long exclusive_dir_mask(unsigned long mask) > > Would you mind terribly if I call that: invert_dir_mask() ? That's indeed much better. > > > +{ > > + unsigned long excl; > > + > > + /* Invert dir */ > > + excl = (mask & LOCKF_ENABLED_IRQ_ALL) >> LOCK_USAGE_DIR_MASK; > > + excl |= (mask & LOCKF_USED_IN_IRQ_ALL) << LOCK_USAGE_DIR_MASK; > > + > > + return excl; > > +} > > + > > +static unsigned long exclusive_mask(unsigned long mask) > > +{ > > + unsigned long excl = exclusive_dir_mask(mask); > > + > > + /* Strip read */ > > + excl |= (excl & LOCKF_IRQ_READ) >> LOCK_USAGE_READ_MASK; > > + excl &= ~LOCKF_IRQ_READ; > > + > > + return excl; > > +} > > And I might write a comment to go with those functions; they're too > clever by half. I'm sure I'll have forgotten how they work in a few > months time. It only takes a night for me to forget how my code works. Then I need a whole day long to recollect. But once I'm done the next night starts. So I'm not against comments, thanks :-) > > +/* > > + * Find the first pair of bit match between an original > > + * usage mask and an exclusive usage mask. > > + */ > > +static int find_exclusive_match(unsigned long mask, > > + unsigned long excl_mask, > > + enum lock_usage_bit *bit, > > + enum lock_usage_bit *excl_bit) > > +{ > > + int fs, nr = 0; > > + > > + while ((fs = ffs(mask))) { > > + int excl; > > + > > + nr += fs; > > + excl = exclusive_bit(nr - 1); > > + if (excl_mask & lock_flag(excl)) { > > + *bit = nr - 1; > > + *excl_bit = excl; > > + return 0; > > + } > > + mask >>= fs - 1; > > + /* > > + * Prevent from shifts of sizeof(long) which can > > + * give unpredictable results. > > + */ > > + mask >>= 1; > > + } > > + return -1; > > Should we write that like: > > for_each_set_bit(bit, &mask, LOCK_USED) { > int excl = exclusive_bit(bit); > if (excl_mask & lock_flag(excl)) { > *bitp = bit; > *excl_bitp = excl; > return 0; > } > } > return -1; > > Or something along those lines? Ah yes indeed. Linus didn't like the idea of using bitmap functions for lockdep usage bits in the softirq vector patchset but here the case is different as it's not used in lockdep fastpath. That's only for the bad locking scenario path so it's all good I think. Should I re-issue the set or you do the changes? Thanks.