Received: by 2002:a05:6a10:6741:0:0:0:0 with SMTP id w1csp780494pxu; Tue, 11 Aug 2020 15:25:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyeRn9jghxlc4tsYffnvUICc+QC2IQYu0xYyzHlBKtKoyFgBRUDdoy1x2r3ezrolLCNy4PA X-Received: by 2002:a17:906:60d5:: with SMTP id f21mr28295436ejk.94.1597184742039; Tue, 11 Aug 2020 15:25:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597184742; cv=none; d=google.com; s=arc-20160816; b=tpfuskdiHZW1ic2H80wb3In461KHFdb3QGc/OJAvft7OE5LHXnDVL+MsM/NNcaMPs2 3p43gFfX938FyJtIXUoW7ImGfxfLIfffLdei3/+jyYgmshtFaw3HZ8e7XacgyfC568BW Gv4thqyHD/9V+PR4S9ZnC97Ze2bH58MSQfdRJV+9MRO62dCX5C6CLYO1BttGGFokfsFp h35WGyBC90M8+HDWm5RxfMaPKRH6SnQu8zzQpo5GwTQ5z4Cjl0LCei7f5Xmlyw2m0JoW U6EPS9DQxMOBaiwH72+qzYPXmsVvIyKIrWZgpX4fQfHYkgerN1FVWY8dS2JrsM4QpJOJ JcGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=W/huS475fQsIt3TnWXWCkTB3aVVuQSvTxEVuKvlu6dg=; b=j3td7RrweYtbXq9+Ly/JgumPR6oZS5GWQC7I43j5OyTCLhsbmpCpjkOfgwbB1DZDSh 5AUND+7jRSPDn9GPhe5WMrheOdWuDmHo9W7fe5xQAYmkfvdRbBg8aJY4Zboq2KPjO8Gv kqGwb4EqKOaMvKgKIpHJ5ObmF192BSlDuYWkoasmWmu6zAdlW0LnK+EffO7lL55DyVZX RO+qTdb5SR1yzTyG+nBEvpigZuyrmYbv9YIe+JfIPuRsyTiqV/9bep3IGzB370IfOwzd dwCmhK7k0v1Ul8GBrYuDbJBaSEe8sZGv8zTdHuTJMvbkwIigJREhJO3dUvP7DrPsOA0C tofA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=j2qZHmeg; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lc20si13684808ejb.468.2020.08.11.15.25.00; Tue, 11 Aug 2020 15:25:42 -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=pass header.i=@google.com header.s=20161025 header.b=j2qZHmeg; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726271AbgHKWWk (ORCPT + 99 others); Tue, 11 Aug 2020 18:22:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39186 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726115AbgHKWWj (ORCPT ); Tue, 11 Aug 2020 18:22:39 -0400 Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 240D8C061787 for ; Tue, 11 Aug 2020 15:22:39 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id h16so399021oti.7 for ; Tue, 11 Aug 2020 15:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W/huS475fQsIt3TnWXWCkTB3aVVuQSvTxEVuKvlu6dg=; b=j2qZHmegCEhDNspLauyB+kdVvkes8CWrlZcQqRI1LHyAMo5fB60/BzJDDlu07DLbob izAX8Dc4i9szyBWt1R7ga4E4pS1VjAfpm1tUutFiNhm2UIc3kJn0W0O6RdI6wzEgnxlH /MTvu4zc4HmX78TaVarH5jtHRol934wJjTOCOQDKvg4Bab1J3H96JCcd8SrN9CNNkd5C 581sNDvs/rxYEFOVfutD8+GyEyM3I25/3MgPbyRn/mfIpNb8EHVJ2YPWFJJz1UORjnNt xM2nMDX3m73d0KHhVn4eQPEQXozuBcclCTfOZhc0JSuzY/69fgfuf7ytGCTrZ/E9lZlN mslw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W/huS475fQsIt3TnWXWCkTB3aVVuQSvTxEVuKvlu6dg=; b=ZIjjMSf3ua7mdBDp+ylF55nRgX10ZxFyu8HCdV93IrwypUgf9yv2Yj49jqtyYcgFtF nwd0YURw3RsJgN8w2b+qei2dp5NLO/iK5lZ82JO7YqOXY+OtgPMTCsULbdpxSwXK2K0B MDA+4JkCXZ8c4rmrRkqb1/LNGO4oyxeS/n6AQfnf7iw7e726+udTmse4+Etip56ryrvP oLW74aNKG8lMAkBoUD7HC0kre0pspm2LPiwU6YfqDS3cTor6qf5K1S7N/ZQafhvXaCF9 FZyg4Gq0oVXx3ZcC0K8XeFWcXKnpVbRrsa6uAMLpmk1oh57cfJAxrylG9qt4JG5vNGnt OQLA== X-Gm-Message-State: AOAM5329+KwCuH9jk0TU0aDlq398P955V8EZgcLR2E6mo98g7IvvZuRD FxrslqFUgPfciM0gaa6aYTHY5uLLsyZJANfMB/4Rng== X-Received: by 2002:a9d:450a:: with SMTP id w10mr6980762ote.327.1597184557742; Tue, 11 Aug 2020 15:22:37 -0700 (PDT) MIME-Version: 1.0 References: <20200810213257.438861-1-urielguajardojr@gmail.com> <20200810214328.GM3982@worktop.programming.kicks-ass.net> <20200811190517.GG2674@hirez.programming.kicks-ass.net> In-Reply-To: <20200811190517.GG2674@hirez.programming.kicks-ass.net> From: Uriel Guajardo Date: Tue, 11 Aug 2020 17:22:26 -0500 Message-ID: Subject: Re: [PATCH] kunit: added lockdep support To: Peter Zijlstra Cc: Uriel Guajardo , Brendan Higgins , mingo@redhat.com, will@kernel.org, "open list:KERNEL SELFTEST FRAMEWORK" , kunit-dev@googlegroups.com, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" 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 2:05 PM wrote: > > 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. Ah, ok! Fair enough, thanks for the info. Although resetting lockdep would be nice to have in the future, I think it's enough to only report the first failure and warn the user that further test cases will have lockdep disabled. People can then fix the issue and then re-run it. I'll follow up with a patch that does this.