From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A427DC369DF for ; Wed, 25 Sep 2024 12:56:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EAA326B00A7; Wed, 25 Sep 2024 08:56:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E59F36B00A8; Wed, 25 Sep 2024 08:56:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D21F66B00A9; Wed, 25 Sep 2024 08:56:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B6DFB6B00A7 for ; Wed, 25 Sep 2024 08:56:57 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 72882160635 for ; Wed, 25 Sep 2024 12:56:57 +0000 (UTC) X-FDA: 82603260474.14.D436DF1 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf03.hostedemail.com (Postfix) with ESMTP id 80B782000B for ; Wed, 25 Sep 2024 12:56:55 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=g6s6zdq0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727268979; a=rsa-sha256; cv=none; b=w+sk0jFBdZarmojzndsRNOnsRetFQCmgUCL/pBSlWbBGny4zkLqmrJI4XnKYj0NWtUxOcZ 2it3vmXW/jni/4ELV54zmTeMSph5xf+8L9bBFhi3+wd2QUReZ2jQgVAPTv6YjEG2lBdzPX ghtb8SKjPitQmj6i5w9tHrlwLa7liwE= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=g6s6zdq0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727268979; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=3fxAT9AVfLIeN6rjTVrSeohwxgf70dKlprguYeTQ+CE=; b=24UlQypNJGNBVGYlZ+/lP/LMyPgfUU3OYfSnlnMz0O1M94Dc1QfdaQC4CwcA5yYkyNYGSF a1uUgvKs6x0sULsDI9xOOuqFuiInx9GosMpi6IHJrgKqLYu3xVi2FlGcOrImnYUYemXhmh 24Qv2oOWvvIQqgT8m7cUylge53mnpUo= Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-536748c7e9aso1346790e87.0 for ; Wed, 25 Sep 2024 05:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727269014; x=1727873814; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3fxAT9AVfLIeN6rjTVrSeohwxgf70dKlprguYeTQ+CE=; b=g6s6zdq0R5vrhXpqNAy5X0qBDblZD7T4SOtR1LUwbEtPaaxUntBLk533Uv8uF+hTzc bvgPwe996xYG6UgMs8a2NA1TdHmis0kODOSJl32rZoEJr4fKsnstLUAJp/tm/nODp99a Plvy8toUSSsVxZfmIs6CQ+l4v4uSqmaHGyQjJNuj9c5Odpe6+JhPaG/aBeivDbsy+o1D pHmoYO0pGa/x6DX3rIcxnR+nkzrP3GzXEeWVltTZGzVaSAU61ZKHdwC5BLXpgilD6MFd OvWV/VuT00izxFEBPa36y+5z6hFvBgleGRxCWYLH048I+XG0yU9ZcRLSIM/5kjVnAQNc E2TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727269014; x=1727873814; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3fxAT9AVfLIeN6rjTVrSeohwxgf70dKlprguYeTQ+CE=; b=sx92tMpQZL04uINg7x0DlGsqk6XtRgcvCPxK5+XsD6tp9gieXJEmr+XAuo/qHZ5h3u GAAi0oyfgj3FgUwKY95JgQ+UqB4rs80Sxp1hy/gEeSuTqsLbBrAgG3ezukPwcxfOiNxC MuVvruGEeuKfnpiistzqoIF5VW22UE5WHPsuP8CwSY7OrYKq4CjMA/+ROEFmM5Uwwq/w eoL3hPRWJOH57MIp+eiQANZMlvm9po8kIx3t4VvBl9yrFB+x5yf21sJlS9eU+qLKa0u1 7djpUgsIfR+WdMG13Mg6m+Wu1wpTYoQAFhSIXLUZEZOCgqJsnpXW2ZKSl5NSJEJKYlRH 6s3w== X-Forwarded-Encrypted: i=1; AJvYcCVUi4EzHQu4UvSu7eKMAYgFD0nwappitAcVCLI6X+nTuueaa1IhlwpbARHJ/UdqoSTEhbfug4vaEw==@kvack.org X-Gm-Message-State: AOJu0YwX5fxT6zndWWga/iK2c8SgS9wBMkGaMXgMmyzWaf38jvnVv4M1 yckwbwTWpMiSqVd+7ATnPePjVbobf8p26K+p0LkpaQqezR6Qxggj34oeFgNpmAOn/voq+2e/SQE kfvJethzvAbIvcuLU7tf6q0pgxEI= X-Google-Smtp-Source: AGHT+IG2RdlFyeWRvaEGDdt+1AxrtErQa9D9ipkPti5nYA90xXjvvPF2uBQnA766jIJPAMkrSvh2PIdI9Qj8zx/I20o= X-Received: by 2002:a05:6512:4019:b0:52c:86d7:fa62 with SMTP id 2adb3069b0e04-53877538cc6mr1823486e87.23.1727269013251; Wed, 25 Sep 2024 05:56:53 -0700 (PDT) MIME-Version: 1.0 References: <20240807-b4-slab-kfree_rcu-destroy-v2-0-ea79102f428c@suse.cz> <20240807-b4-slab-kfree_rcu-destroy-v2-7-ea79102f428c@suse.cz> <6fcb1252-7990-4f0d-8027-5e83f0fb9409@roeck-us.net> <07d5a214-a6c2-4444-8122-0a7b1cdd711f@suse.cz> <73f9e6d7-f5c0-4cdc-a9c4-dde3e2fb057c@roeck-us.net> <474b0519-b354-4370-84ac-411fd3d6d14b@suse.cz> In-Reply-To: From: Hyeonggon Yoo <42.hyeyoo@gmail.com> Date: Wed, 25 Sep 2024 21:56:40 +0900 Message-ID: Subject: Re: [PATCH v2 7/7] kunit, slub: add test_kfree_rcu() and test_leak_destroy() To: Guenter Roeck Cc: Vlastimil Babka , KUnit Development , Brendan Higgins , David Gow , "Paul E. McKenney" , Joel Fernandes , Josh Triplett , Boqun Feng , Christoph Lameter , David Rientjes , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Julia Lawall , Jakub Kicinski , "Jason A. Donenfeld" , "Uladzislau Rezki (Sony)" , Andrew Morton , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, rcu@vger.kernel.org, Alexander Potapenko , Marco Elver , Dmitry Vyukov , kasan-dev@googlegroups.com, Jann Horn , Mateusz Guzik Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 80B782000B X-Rspamd-Server: rspam01 X-Stat-Signature: gni3g663jkedeza38ha7gt47pcazrxdg X-HE-Tag: 1727269015-352917 X-HE-Meta: U2FsdGVkX1/gL8YMXoN7wrxfgZiWIZafVmsc+qLLRxmin30FBvFH+SsMQHebXIYGw5yEive/XSCKDQVMdp9N0raoYJzWEu6hI/a2sJyUI5wjALvRY+3aUFTvfUNDerKZB34sVOJXOAUwB7h28rUi19pv48nQr6xWjzVi2iJS1RUSM7bLG88yOQpwt/Snfppvxcy+9onVsILyrfvHlVn23vyqMVo0c6xOcholP2YdnR28Ui8HCc+GOlTFyTaXV/smxMeJx6XXlICZbE8nDOKQdRLo301oUaHUj26z6/11VZrOAAPjP6flOTROWAHnJQTle8jnx4gp6W/Vx0Jw1wLSGuO/wuiGMLKyGTn06ZgApryFsLgLRy8/FFdJjNqwhqAXzBIThBphpqRMwbQBRW4EDD1S8yfye6vnPVXwgfECBXyZIpPM+m7de9eSiwmKA7tWsDMuU8QzAyu0PFNsF0YU3T9Zq1s7h4OPEjSf572UrGqun6EUH9/f+G8fGUQFvX5L5VpfxQBtguSBiaG+4IxWIbrh4G1y9TeO2P+I6sFZqSiS9qk7zJ4mH3Ly5R4Brc0lNDuLCGGI1rwW1T4xVuhVTv24KeQCPZCcv4GolVzFiWhnVT8acPYvVmDKoB1TW/0SRTeDU+iSX5DzMPuQLsNYAOy6e33G/R2/jKxuw4pTerl6HtfuANuscXjzJVsLC4ZetPGjLTEtaJievwDGtTwubUCRK6PwmYapYtFODw+A6QOJPuOO4Y5mK0Meo0kLPOS0cbg4BYiHxBSOPexO/znUIb7fgKUueATT7HlBYqvVOF3/jnn+dQFVtG/vr5KQxbn8YD72B8WY5or1byzZq014wi29Y/AP6t7k514867/Nxx3EhbLjg7cLdfkXOGQIL0jFN1Uwf85SD6Hf0wWzYHv9yPkAghqohAPmjGpAetZWExJCu8x8vGjTkO06IuuF3UKse11zjtMnTGhhakS7HhZ ppMGSA6F 1dyoIj17CIbGLGZn5a67jU2Zshf/l4mbp+Y6MS5402rmanmGdnC1cRiG6WkC6Vjri2dpNRSRsYorUnBAKlXRK1zck92pq+d5mwWj/5PUhHd2cLpO6ppj6ogZWVySjklJiRKhn1W6Kh21lqA+axTpleVsnGfVMywWHB3YU+gsG7zl5uZ2IjhRCxaT8VDWNY3l6sZUHqiOzpoOuB+0/GBwYU1dl+57nHC6F/QVu1VwC4a0v3VfEMEwRSGu74JThDiSKqJFoGc6vQ+JnD4re/868F8oiegSH4AIS7Q4kzjCeblNr+QJ9iS4G295wkxfGwK+iGjxcR5XkWVYPs1fhL6qnoa+Q/6p6pM3i18RRw0crrG92YMLJ6EGgGyo0ahBnhYaHh/AbGHDNNUXEvyu/oCnGMKUC3qbvtsJJNavLSBHpnM8Ycks8UjuF9JE9LNrfRyfIHi5MZGMIjcmpABYStxHsMG6UrlJenx3+IcYZBw6jKTN728CpsxLdnzrljgQ/3LOj5aS+y3oz7mv/DoMudm4xJpxP4A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sun, Sep 22, 2024 at 11:13=E2=80=AFPM Guenter Roeck = wrote: > > On 9/21/24 23:16, Hyeonggon Yoo wrote: > > On Sun, Sep 22, 2024 at 6:25=E2=80=AFAM Vlastimil Babka wrote: > >> > >> On 9/21/24 23:08, Guenter Roeck wrote: > >>> On 9/21/24 13:40, Vlastimil Babka wrote: > >>>> +CC kunit folks > >>>> > >>>> On 9/20/24 15:35, Guenter Roeck wrote: > >>>>> Hi, > >>>> > >>>> Hi, > >>>> > >>>>> On Wed, Aug 07, 2024 at 12:31:20PM +0200, Vlastimil Babka wrote: > >>>>>> Add a test that will create cache, allocate one object, kfree_rcu(= ) it > >>>>>> and attempt to destroy it. As long as the usage of kvfree_rcu_barr= ier() > >>>>>> in kmem_cache_destroy() works correctly, there should be no warnin= gs in > >>>>>> dmesg and the test should pass. > >>>>>> > >>>>>> Additionally add a test_leak_destroy() test that leaks an object o= n > >>>>>> purpose and verifies that kmem_cache_destroy() catches it. > >>>>>> > >>>>>> Signed-off-by: Vlastimil Babka > >>>>> > >>>>> This test case, when run, triggers a warning traceback. > >>>>> > >>>>> kmem_cache_destroy TestSlub_kfree_rcu: Slab cache still has objects= when called from test_leak_destroy+0x70/0x11c > >>>>> WARNING: CPU: 0 PID: 715 at mm/slab_common.c:511 kmem_cache_destroy= +0x1dc/0x1e4 > >>>> > >>>> Yes that should be suppressed like the other slub_kunit tests do. I = have > >>>> assumed it's not that urgent because for example the KASAN kunit tes= ts all > >>>> produce tons of warnings and thus assumed it's in some way acceptabl= e for > >>>> kunit tests to do. > >>>> > >>> > >>> I have all tests which generate warning backtraces disabled. Trying t= o identify > >>> which warnings are noise and which warnings are on purpose doesn't sc= ale, > >>> so it is all or nothing for me. I tried earlier to introduce a patch = series > >>> which would enable selective backtrace suppression, but that died the= death > >>> of architecture maintainers not caring and people demanding it to be = perfect > >>> (meaning it only addressed WARNING: backtraces and not BUG: backtrace= s, > >>> and apparently that wasn't good enough). > >> > >> Ah, didn't know, too bad. > >> > >>> If the backtrace is intentional (and I think you are saying that it i= s), > >>> I'll simply disable the test. That may be a bit counter-productive, b= ut > >>> there is really no alternative for me. > >> > >> It's intentional in the sense that the test intentionally triggers a > >> condition that normally produces a warning. Many if the slub kunit tes= t do > >> that, but are able to suppress printing the warning when it happens in= the > >> kunit context. I forgot to do that for the new test initially as the w= arning > >> there happens from a different path that those that already have the k= unit > >> suppression, but we'll implement that suppression there too ASAP. > > > > We might also need to address the concern of the commit > > 7302e91f39a ("mm/slab_common: use WARN() if cache still has objects on > > destroy"), > > the concern that some users prefer WARN() over pr_err() to catch > > errors on testing systems > > which relies on WARN() format, and to respect panic_on_warn. > > > > So we might need to call WARN() instead of pr_err() if there are errors= in > > slub error handling code in general, except when running kunit tests? > > > > If people _want_ to see WARNING backtraces generated on purpose, so be it= . > For me it means that _real_ WARNING backtraces disappear in the noise. > Manually maintaining a list of expected warning backtraces is too mainten= ance > expensive for me, so I simply disable all kunit tests which generate > backtraces on purpose. That is just me, though. Other testbeds may have > more resources available and may be perfectly happy with the associated > maintenance cost. > > In this specific case, I now have disabled slub kunit tests, and, as > mentioned before, from my perspective there is no need to change the > code just to accommodate my needs. I'll do the same with all other new > unit tests which generate backtraces in the future, without bothering > anyone. > > Sorry for the noise. I don't think this was a noise :) IMO some people want to see WARNING during testing to catch errors, but not for the slub_kunit test case. I think a proper approach here would be suppressing warnings while running slub_kunit test cases, but print WARNING when it is not running slub_kunit test cases. That would require some work changing the slub error reporting logic to print WARNING on certain errors. Any opinions, Vlastimil? Thanks, Hyeonggon