From patchwork Tue Jun 29 02:34:43 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12348925 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30658C11F66 for ; Tue, 29 Jun 2021 02:34:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DAC5461A1D for ; Tue, 29 Jun 2021 02:34:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DAC5461A1D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 392538D0090; Mon, 28 Jun 2021 22:34:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31B4B8D008F; Mon, 28 Jun 2021 22:34:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BBFA8D0090; Mon, 28 Jun 2021 22:34:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0100.hostedemail.com [216.40.44.100]) by kanga.kvack.org (Postfix) with ESMTP id E15C48D008F for ; Mon, 28 Jun 2021 22:34:44 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D8DD28249980 for ; Tue, 29 Jun 2021 02:34:44 +0000 (UTC) X-FDA: 78305193288.34.FDAC232 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf15.hostedemail.com (Postfix) with ESMTP id 8D86AA0010D9 for ; Tue, 29 Jun 2021 02:34:44 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 62C2261CEF; Tue, 29 Jun 2021 02:34:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1624934083; bh=wlhS2E2HZLv8akGNQH5URCXZ0QNDoQvNpKNwGdbsDao=; h=Date:From:To:Subject:In-Reply-To:From; b=j02zDDc7Xy5+5lyRsdDUGkAUSULYz7vdPD5ZUxH4sCarVjPhb8bAPDTySErzifTeD I0K2l8251h9U/82YhYPftvtTmuBG/pFpzmn0YEWp//smYm/x0js4+kZ86vAxazR6MB w0VL55JHR2qYo/Q8co8VB8jHWX2BkKNIICC0uTbg= Date: Mon, 28 Jun 2021 19:34:43 -0700 From: Andrew Morton To: akpm@linux-foundation.org, cl@linux.com, iamjoonsoo.kim@lge.com, joe@perches.com, linux-mm@kvack.org, mm-commits@vger.kernel.org, penberg@kernel.org, pmladek@suse.com, rientjes@google.com, songmuchun@bytedance.com, swboyd@chromium.org, torvalds@linux-foundation.org, vbabka@suse.cz Subject: [patch 027/192] slub: restore slub_debug=- behavior Message-ID: <20210629023443.gV9pF8mwV%akpm@linux-foundation.org> In-Reply-To: <20210628193256.008961950a714730751c1423@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 8D86AA0010D9 X-Stat-Signature: c5q1qmmc1wt8r75geh7oakbc86danxiw Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=j02zDDc7; dmarc=none; spf=pass (imf15.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-HE-Tag: 1624934084-543398 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: From: Stephen Boyd Subject: slub: restore slub_debug=- behavior Petch series "slub: Print non-hashed pointers in slub debugging", v3. I was doing some debugging recently and noticed that my pointers were being hashed while slub_debug was on the kernel commandline. Let's force on the no hash pointer option when slub_debug is on the kernel commandline so that the prints are more meaningful. The first two patches are something else I noticed while looking at the code. The message argument is never used so the debugging messages are not as clear as they could be and the slub_debug=- behavior seems to be busted. Then there's a printf fixup from Joe and the final patch is the one that force disables pointer hashing. This patch (of 4): Passing slub_debug=- on the kernel commandline is supposed to disable slub debugging. This is especially useful with CONFIG_SLUB_DEBUG_ON where the default is to have slub debugging enabled in the build. Due to some code reorganization this behavior was dropped, but the code to make it work mostly stuck around. Restore the previous behavior by disabling the static key when we parse the commandline and see that we're trying to disable slub debugging. Link: https://lkml.kernel.org/r/20210601182202.3011020-1-swboyd@chromium.org Link: https://lkml.kernel.org/r/20210601182202.3011020-2-swboyd@chromium.org Fixes: ca0cab65ea2b ("mm, slub: introduce static key for slub_debug()") Signed-off-by: Stephen Boyd Acked-by: Vlastimil Babka Reviewed-by: Muchun Song Cc: Christoph Lameter Cc: David Rientjes Cc: Joe Perches Cc: Joonsoo Kim Cc: Pekka Enberg Cc: Petr Mladek Signed-off-by: Andrew Morton --- mm/slub.c | 2 ++ 1 file changed, 2 insertions(+) --- a/mm/slub.c~slub-restore-slub_debug=-behavior +++ a/mm/slub.c @@ -1429,6 +1429,8 @@ static int __init setup_slub_debug(char out: if (slub_debug != 0 || slub_debug_string) static_branch_enable(&slub_debug_enabled); + else + static_branch_disable(&slub_debug_enabled); if ((static_branch_unlikely(&init_on_alloc) || static_branch_unlikely(&init_on_free)) && (slub_debug & SLAB_POISON))