Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp675644pxa; Tue, 11 Aug 2020 12:08:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzy5ywPwcNV2CMN9pSZIfA2DIdgw77PTbeEKhcN2dwmEeHUW9R1u/6Q9fy6sxrUPvZaJdh1 X-Received: by 2002:a17:906:bc52:: with SMTP id s18mr18886835ejv.298.1597172894026; Tue, 11 Aug 2020 12:08:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597172894; cv=none; d=google.com; s=arc-20160816; b=Ilci0fNBeRW0U0qUPbXmW5s78oyZwsYi56uYLWkuoDPnWP4z9My8kpKd+2s/FLR48p prkMgBbYWCr3n/xoui7sd4k0KB87V+xPyDHqzBzawL2O05+4YKSY3zKjywU9LSmBxm7+ DZwbYPL3qPDmgisJ+59uclolx4aNGuE9wXFamttYrnTAA2J1esDBHm3DPh/Y4td19oUY BiMVncHriT8VWCn8cUB+gFHAYxnUpgqRZmHczwSxk1pjUSuDQBPz6VVkgA2aPb++bnmT /OX1MH5BcM6SNZrJbLMRX9ugwMehtSyCtfGF2xEfpsbZznqg8lJ7vL0BscUbBYihfyH9 qnNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=REGRP0wT2GfbQ/FutuiotQ+2f7Plfx/4XOzG7gnERs4=; b=jEiWNhkxbRtuB7DSLTpt0sJkmLKqNfdnOK2OP1CkD7LKfisDZNVnTPOtKSwLwkMWhT EWHniTyyARSa4HPSBBCGR7Tpa8tJZjEhX4WXLzdE5lx0csn//6gBjm6tNIZhLbGfBWA1 kOru1GPV2kuo5PcfgTYekn2/M11RHUt4QyknchECWgcit9wbA0tSUoXG1PsiXAF4Sq3T kWFy7u6HA1FaRjZfAhlZ+GN79zUMkzZeTokP3RkZmlwJItc27CMywa3J+Dei28KVSkZb tnl5/7KEyPcYvajTNMQfblhsHVgeGQuuz4yIY1ryEh423ejDCl04VQAUWTZYTG7wJJdY m6VA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=PK5m21KG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o17si13563573ejg.156.2020.08.11.12.07.50; Tue, 11 Aug 2020 12:08:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=PK5m21KG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726255AbgHKTF2 (ORCPT + 99 others); Tue, 11 Aug 2020 15:05:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725886AbgHKTF1 (ORCPT ); Tue, 11 Aug 2020 15:05:27 -0400 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 44F13C06174A; Tue, 11 Aug 2020 12:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=REGRP0wT2GfbQ/FutuiotQ+2f7Plfx/4XOzG7gnERs4=; b=PK5m21KGU3UK/ex0YwGzUQ/S2z UvXnuXDgbUrj2i7OxztELNv/S2/KxgsmT/37rIAgr/cDDhreyKyUT4BAya5PQX6coI+oJdCOXLVSP HqNt+HaSfdciCw5A3/CENvWdghUPtPr+l8nMRJtz8YMKiQ6Izz12jWePewymRvIdI2V3isy3tdL5N yBSWjrF0s27WvJ2GiqhEEMcvG41vBLQSsGvY5hVnMe7rJ+juNV1LrsaW6ZS6AfbNR8r8Wp8uiJUNj eUndKylrBKDxZwZgydybz4O5f+Ddk3AWzCHga/llUPkJsvXkdmxX0hMhPg/BRRCpkT3Od8DrdebV8 UZA3ZvLA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1k5ZaI-0001MX-Ng; Tue, 11 Aug 2020 19:05:18 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 2E2CD3028C8; Tue, 11 Aug 2020 21:05:17 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 1604B2110CB33; Tue, 11 Aug 2020 21:05:17 +0200 (CEST) Date: Tue, 11 Aug 2020 21:05:17 +0200 From: peterz@infradead.org To: Uriel Guajardo Cc: Uriel Guajardo , Brendan Higgins , mingo@redhat.com, will@kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , kunit-dev@googlegroups.com, Linux Kernel Mailing List Subject: Re: [PATCH] kunit: added lockdep support Message-ID: <20200811190517.GG2674@hirez.programming.kicks-ass.net> References: <20200810213257.438861-1-urielguajardojr@gmail.com> <20200810214328.GM3982@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 11, 2020 at 12:03:51PM -0500, Uriel Guajardo wrote: > On Mon, Aug 10, 2020 at 4:43 PM Peter Zijlstra wrote: > > > > On Mon, Aug 10, 2020 at 09:32:57PM +0000, Uriel Guajardo wrote: > > > +static inline void kunit_check_locking_bugs(struct kunit *test, > > > + unsigned long saved_preempt_count) > > > +{ > > > + preempt_count_set(saved_preempt_count); > > > +#ifdef CONFIG_TRACE_IRQFLAGS > > > + if (softirq_count()) > > > + current->softirqs_enabled = 0; > > > + else > > > + current->softirqs_enabled = 1; > > > +#endif > > > +#if IS_ENABLED(CONFIG_LOCKDEP) > > > + local_irq_disable(); > > > + if (!debug_locks) { > > > + kunit_set_failure(test); > > > + lockdep_reset(); > > > + } > > > + local_irq_enable(); > > > +#endif > > > +} > > > > Unless you can guarantee this runs before SMP brinup, that > > lockdep_reset() is terminally broken. > > Good point. KUnit is initialized after SMP is set up, and KUnit can > also be built as a module, so it's not a guarantee that we can make. Even if you could, there's still the question of wether throwing out all the dependencies learned during boot is a sensible idea. > Is there any other way to turn lockdep back on after we detect a > failure? It would be ideal if lockdep could still run in the next test > case after a failure in a previous one. Not really; the moment lockdep reports a failure it turns off all tracking and we instantly loose state. You'd have to: - delete the 'mistaken' dependency from the graph such that we loose the cycle, otherwise it will continue to find and report the cycle. - put every task through a known empty state which turns the tracking back on. Bart implemented most of what you need for the first item last year or so, but the remaining bit and the second item would still be a fair amount of work. Also, I'm really not sure it's worth it, the kernel should be free of lock cycles, so just fix one, reboot and continue. > I suppose we could only display the first failure that occurs, similar > to how lockdep does it. But it could also be useful to developers if > they saw failures in subsequent test cases, with the knowledge that > those failures may be unreliable. People already struggle with lockdep reports enough; I really don't want to given them dodgy report to worry about.