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;
MIME-Version: 1.0
References: <20200812193332.954395-1-urielguajardojr@gmail.com> <20200813103615.GT2674@hirez.programming.kicks-ass.net>
In-Reply-To: <20200813103615.GT2674@hirez.programming.kicks-ass.net>
From:   Uriel Guajardo <urielguajardo@google.com>
Date:   Thu, 13 Aug 2020 08:15:27 -0500
Message-ID: <CAG30Eec2w1zG7CEd=TVGoNssCZu49TBF+1xXPKrKh+d7hJZfsg@mail.gmail.com>
Subject: Re: [PATCH v2] kunit: added lockdep support
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Uriel Guajardo <urielguajardojr@gmail.com>,
        Brendan Higgins <brendanhiggins@google.com>, mingo@redhat.com,
        will@kernel.org,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@vger.kernel.org>, kunit-dev@googlegroups.com,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Aug 13, 2020 at 5:36 AM <peterz@infradead.org> wrote:
>
> On Wed, Aug 12, 2020 at 07:33:32PM +0000, Uriel Guajardo wrote:
> > KUnit will fail tests upon observing a lockdep failure. Because lockdep
> > turns itself off after its first failure, only fail the first test and
> > warn users to not expect any future failures from lockdep.
> >
> > Similar to lib/locking-selftest [1], we check if the status of
> > debug_locks has changed after the execution of a test case. However, we
> > do not reset lockdep afterwards.
> >
> > Like the locking selftests, we also fix possible preemption count
> > corruption from lock bugs.
>
> > +static void kunit_check_locking_bugs(struct kunit *test,
> > +                                  unsigned long saved_preempt_count,
> > +                                  bool saved_debug_locks)
> > +{
> > +     preempt_count_set(saved_preempt_count);
> > +#ifdef CONFIG_TRACE_IRQFLAGS
> > +     if (softirq_count())
> > +             current->softirqs_enabled = 0;
> > +     else
> > +             current->softirqs_enabled = 1;
> > +#endif
>
> Urgh, don't silently change these... if they're off that's a hard fail.
>
>         if (DEBUG_LOCKS_WARN_ON(preempt_count() != saved_preempt_count))
>                 preempt_count_set(saved_preempt_count);
>
> And by using DEBUG_LOCKS_WARN_ON() it will kill IRQ tracing and trigger
> the below fail.

Hmm, I see. My original assumption was that lock related bugs that
could corrupt preempt_count would always be intervened by lockdep
(resulting in debug_locks already being off). Is this not always true?
In any case, I think it's better to explicitly show the failure
associated with preemption count as you have done, but I'm still
curious.

Also, for further clarification: the check you have made on
preempt_count also covers softirq_count, right? My understanding is
that softirqs are re-{enabled/disabled} due to the corruption of the
preemption count, so no changes should occur if the preemption count
remains the same. If it does change, we've already failed from
DEBUG_LOCKS_WARN_ON.

>
> > +     if (saved_debug_locks && !debug_locks) {
> > +             kunit_set_failure(test);
> > +             kunit_warn(test, "Dynamic analysis tool failure from LOCKDEP.");
> > +             kunit_warn(test, "Further tests will have LOCKDEP disabled.");
> > +     }
> > +}