Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp665968pxf; Thu, 8 Apr 2021 10:21:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy5JajoVogPh3jXjiIq066zLywTW2KfjDsSnxoT2QfynSAbjGvrAHr9SUqUj+CHF0aQZJwC X-Received: by 2002:a17:906:d555:: with SMTP id cr21mr5102551ejc.66.1617902471556; Thu, 08 Apr 2021 10:21:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617902471; cv=none; d=google.com; s=arc-20160816; b=E0gsHS2WCwQkCHbyB/ENxKnWqoWTycs2eW7WDzvAPwNfrNFhFOWct/B1+wWSgWU6IL xxtjuUvezWCGngwnZKej53PWi75DdWMWBydcMODcBLQxNXPeo4mvjcmfJKQMEYfJxa3L g9mTsl2BBrmrbqKuEgAXlQu8JaURcBfZqTmYlIIU+gc7vzZP1q6S8p+E5p/eZ0vrgVHA TlB4Ae2tmNhAWTeJz8tYwVNv+CZ+4v2hFtFpj3WwD6mRaVDDXmsMtHgTku4RS2wNeMlR rdWvKecgVXvAOjBRqda/LWZqvm+97f4KPnbwMRS0PhcVtociSl3DOxKxqHySHDCFSMSV rLKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=AGKJ5TMDA3zjXOa+bUjOOsMpKwnvT3r5d1vND1DMuTk=; b=J/THy/bdyJq/X0p5/WrbrfbXHoUreg4LOJhZIH1+LChDAbiNRAIykWqAnFEJrObAoq qzOU9FvTlAtR80lpA51ppaBVLO2sMxBveX6u1rd0a3KWkl4j+DNu4xAQui37tJUHEFMq 48h7MzYvKfWF3HR5ej9lry0iaMgp8hLIiLqA67suZTO7g65/pCKr/G5Rx7F7w35VM5eV RqLawQoJGfl1TYxb4yeuGPQNnDUdOaAkOkLH8XVH5HYCL31rexqzDMlZsVZDUZk7xj5/ ygY+SKe6xXIc9ErvB+P0oUv19cCfIJTJi1xK0Q4ynpS5ZUOb594XsX0ByR0nu9Q7nknK BClQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=KtD3y5Jd; 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 hb30si23514996ejc.218.2021.04.08.10.20.47; Thu, 08 Apr 2021 10:21:11 -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=KtD3y5Jd; 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 S232599AbhDHRTc (ORCPT + 99 others); Thu, 8 Apr 2021 13:19:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33422 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232574AbhDHRTb (ORCPT ); Thu, 8 Apr 2021 13:19:31 -0400 Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 49BBBC061760 for ; Thu, 8 Apr 2021 10:19:20 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id w2so2416663ilj.12 for ; Thu, 08 Apr 2021 10:19:20 -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=AGKJ5TMDA3zjXOa+bUjOOsMpKwnvT3r5d1vND1DMuTk=; b=KtD3y5Jd/oXd9jMLZ7G5Zg920b800bH/ytyAWmiEWwV1pzM2KDnyDAoUtg6U2YKAAu HhzgtAMNgiuFl0SxM5Z425vSBji2Cn6V77jZxAsYlYFm3GPilHcU45nggH5hQPo5mUCN YQqUK221JeyVfrFVRswiNQy48LzX2kMy1O6tpf8975lGRiHM73EqL8s1Obu/zuIfr5QW d8x1LVcqUIynDQI8Cm1XIlQPTCU8kIq4jZitcFkkXxpHjQVYop54OxjQ27aAShHJK8Wm 1NJSb802htKeAtrkLHFCVwm6w6zX5Hg2eQp1NLJlG0ZtHaEpiS+8YMyDjp+8eXfhCXtu 4kZA== 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=AGKJ5TMDA3zjXOa+bUjOOsMpKwnvT3r5d1vND1DMuTk=; b=IZGjbHTAmZ2zawkkE9MIqg1Su4jft++w26ikYRePjqeyCDpvXeO563v2cltX7H8hOf g7NnH4QCkudBSFtQKqyOs/CcoyNZJDRdA1CbxtajDVfLFO2PSjVENYZYfsxCxqSU3H1e 8HvCJmj/5xMgxPQjYS4j9NRfMn85/rb49EKtvQDKHRMnhcKn0CLIFu0EYE5tgGiIx53M /76psa5DpX88D4yzf5zXB6bFPmR9kstMfRExRf3PnDll12WPxhU0zjIQ9pc+VxYoE8eB HDSvLrr0kSOI59W76wSXBdEmDuuJjxqJmwtAd7YZNorbLTyFStTjgzhtbYOGk6eZhdTy bgiw== X-Gm-Message-State: AOAM532xNERxSQEZjN3n4WOwn76u/wVc+XBcu/tKiMQ8E1GtcFCNrSzm BGR+armEIg92dT6KzS5iE8TRncFWiDAJUpCZQLWyMg== X-Received: by 2002:a92:d48c:: with SMTP id p12mr7964592ilg.136.1617902359306; Thu, 08 Apr 2021 10:19:19 -0700 (PDT) MIME-Version: 1.0 References: <20210331085156.5028-1-glittao@gmail.com> <11886d4f-8826-0cd6-b5fd-defc65470ed5@suse.cz> In-Reply-To: From: Daniel Latypov Date: Thu, 8 Apr 2021 10:19:08 -0700 Message-ID: Subject: Re: [PATCH v3 1/2] kunit: add a KUnit test for SLUB debugging functionality To: Marco Elver Cc: Vlastimil Babka , glittao@gmail.com, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Linux Kernel Mailing List , Linux Memory Management List , KUnit Development , Brendan Higgins , David Gow Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 8, 2021 at 3:30 AM Marco Elver wrote: > > On Tue, 6 Apr 2021 at 12:57, Vlastimil Babka wrote: > > > > > > On 4/1/21 11:24 PM, Marco Elver wrote: > > > On Thu, 1 Apr 2021 at 21:04, Daniel Latypov wrote: > > >> > } > > >> > #else > > >> > static inline bool slab_add_kunit_errors(void) { return false; } > > >> > #endif > > >> > > > >> > And anywhere you want to increase the error count, you'd call > > >> > slab_add_kunit_errors(). > > >> > > > >> > Another benefit of this approach is that if KUnit is disabled, there is > > >> > zero overhead and no additional code generated (vs. the current > > >> > approach). > > >> > > >> The resource approach looks really good, but... > > >> You'd be picking up a dependency on > > >> https://lore.kernel.org/linux-kselftest/20210311152314.3814916-2-dlatypov@google.com/ > > >> current->kunit_test will always be NULL unless CONFIG_KASAN=y && > > >> CONFIG_KUNIT=y at the moment. > > >> My patch drops the CONFIG_KASAN requirement and opens it up to all tests. > > > > > > Oh, that's a shame, but hopefully it'll be in -next soon. > > > > > >> At the moment, it's just waiting another look over from Brendan or David. > > >> Any ETA on that, folks? :) > > >> > > >> So if you don't want to get blocked on that for now, I think it's fine to add: > > >> #ifdef CONFIG_SLUB_KUNIT_TEST > > >> int errors; > > >> #endif > > > > > > Until kunit fixes setting current->kunit_test, a cleaner workaround > > > that would allow to do the patch with kunit_resource, is to just have > > > an .init/.exit function that sets it ("current->kunit_test = test;"). > > > And then perhaps add a note ("FIXME: ...") to remove it once the above > > > patch has landed. > > > > > > At least that way we get the least intrusive change for mm/slub.c, and > > > the test is the only thing that needs a 2-line patch to clean up > > > later. > > > > So when testing internally Oliver's new version with your suggestions (thanks > > again for those), I got lockdep splats because slab_add_kunit_errors is called > > also from irq disabled contexts, and kunit_find_named_resource will call > > spin_lock(&test->lock) that's not irq safe. Can we make the lock irq safe? I > > tried the change below and it makde the problem go away. If you agree, the > > question is how to proceed - make it part of Oliver's patch series and let > > Andrew pick it all with eventually kunit team's acks on this patch, or whatnot. > > From what I can tell it should be fine to make it irq safe (ack for > your patch below). Regarding patch logistics, I'd probably add it to > the series. If that ends up not working, we'll find out sooner or > later. > > (FYI, the prerequisite patch for current->kunit_test is in -next now.) Yep. There's also two follow-up patches in https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/log/?h=kunit > > KUnit maintainers, do you have any preferences? Poked offline and Brendan and David seemed fine either way. So probably just include it in this patch series for convenience. Brendan also mentioned KUnit used to use spin_lock_irqsave/restore() but had been told to not use it until necessary. See https://lore.kernel.org/linux-kselftest/20181016235120.138227-3-brendanhiggins@google.com/ So I think there's no objections to the patch itself either. But I'd wait for Brendan to chime in to confirm. > > > ----8<---- > > > > commit ab28505477892e9824c57ac338c88aec2ec0abce > > Author: Vlastimil Babka > > Date: Tue Apr 6 12:28:07 2021 +0200 > > > > kunit: make test->lock irq safe > > > > diff --git a/include/kunit/test.h b/include/kunit/test.h > > index 49601c4b98b8..524d4789af22 100644 > > --- a/include/kunit/test.h > > +++ b/include/kunit/test.h > > @@ -515,8 +515,9 @@ kunit_find_resource(struct kunit *test, > > void *match_data) > > { > > struct kunit_resource *res, *found = NULL; > > + unsigned long flags; > > > > - spin_lock(&test->lock); > > + spin_lock_irqsave(&test->lock, flags); > > > > list_for_each_entry_reverse(res, &test->resources, node) { > > if (match(test, res, (void *)match_data)) { > > @@ -526,7 +527,7 @@ kunit_find_resource(struct kunit *test, > > } > > } > > > > - spin_unlock(&test->lock); > > + spin_unlock_irqrestore(&test->lock, flags); > > > > return found; > > } > > diff --git a/lib/kunit/test.c b/lib/kunit/test.c > > index ec9494e914ef..2c62eeb45b82 100644 > > --- a/lib/kunit/test.c > > +++ b/lib/kunit/test.c > > @@ -442,6 +442,7 @@ int kunit_add_resource(struct kunit *test, > > void *data) > > { > > int ret = 0; > > + unsigned long flags; > > > > res->free = free; > > kref_init(&res->refcount); > > @@ -454,10 +455,10 @@ int kunit_add_resource(struct kunit *test, > > res->data = data; > > } > > > > - spin_lock(&test->lock); > > + spin_lock_irqsave(&test->lock, flags); > > list_add_tail(&res->node, &test->resources); > > /* refcount for list is established by kref_init() */ > > - spin_unlock(&test->lock); > > + spin_unlock_irqrestore(&test->lock, flags); > > > > return ret; > > } > > @@ -515,9 +516,11 @@ EXPORT_SYMBOL_GPL(kunit_alloc_and_get_resource); > > > > void kunit_remove_resource(struct kunit *test, struct kunit_resource *res) > > { > > - spin_lock(&test->lock); > > + unsigned long flags; > > + > > + spin_lock_irqsave(&test->lock, flags); > > list_del(&res->node); > > - spin_unlock(&test->lock); > > + spin_unlock_irqrestore(&test->lock, flags); > > kunit_put_resource(res); > > } > > EXPORT_SYMBOL_GPL(kunit_remove_resource); > > @@ -597,6 +600,7 @@ EXPORT_SYMBOL_GPL(kunit_kfree); > > void kunit_cleanup(struct kunit *test) > > { > > struct kunit_resource *res; > > + unsigned long flags; > > > > /* > > * test->resources is a stack - each allocation must be freed in the > > @@ -608,9 +612,9 @@ void kunit_cleanup(struct kunit *test) > > * protect against the current node being deleted, not the next. > > */ > > while (true) { > > - spin_lock(&test->lock); > > + spin_lock_irqsave(&test->lock, flags); > > if (list_empty(&test->resources)) { > > - spin_unlock(&test->lock); > > + spin_unlock_irqrestore(&test->lock, flags); > > break; > > } > > res = list_last_entry(&test->resources, > > @@ -621,7 +625,7 @@ void kunit_cleanup(struct kunit *test) > > * resource, and this can't happen if the test->lock > > * is held. > > */ > > - spin_unlock(&test->lock); > > + spin_unlock_irqrestore(&test->lock, flags); > > kunit_remove_resource(test, res); > > } > > #if (IS_ENABLED(CONFIG_KASAN) && IS_ENABLED(CONFIG_KUNIT))