Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2901967yba; Mon, 8 Apr 2019 07:08:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqw+NFNRMLcTSRsMx5h7S8NPB1TxDUx/9VNTqUGlNGHQpYXsqz85mdBjhX8h+oqY/sdIIzNb X-Received: by 2002:a17:902:2702:: with SMTP id c2mr11612441plb.37.1554732488661; Mon, 08 Apr 2019 07:08:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554732488; cv=none; d=google.com; s=arc-20160816; b=fLWilwQcYNgRaMXW/i6y/0zq1g+TnQNn5XJdy3ZS7WMhVNrfLQYjlWHItoF2II8O8g uICU2OBCZsS6EmGINbzmz3OWhylFfr/65yRrjqCFe+xGE/HkLRNnezwXkKLU0wN1bRuY Lxt1GvCpt4iZkAA2f1MtngsVJ+lWx89+sZ5iB1g9ceoR1OQxlUrQ9EP3UAAFk4tuoC12 u2EcJBQkBQ5bFNiOzMM8acsZC7viu9MsXBKvm3g9SNw21C2c7f+4sHLhkEGQrVuy6Azu XAGQ9EOxFTIQp5Bs28dk3rxvPS40KhSSr8hRfoJVJS+JQeKFQ6wRx52h11RWK8tWeZB8 CLPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature; bh=dQ1SL9x4bZEYJy4r8vMymO8S+vKZHanfiXAqd5yNVlg=; b=tSkYZVMeCEWbser9FRxkwzYugLsQA0hksBFK/SCb6QHZ7K6iI8hGP8RhERGlqWbXS4 c2i3gvu9xJ9JHVA9Cd56phcxSkMLUIp2lXJPjIMANezt3jziTMjzwmfxSSNsSWurwc+O XMCNB4IeU/qn9aXNIHYTLeplQVd/3YiSLhOoCwBaAwbtALSFA5Dc8efsWf3Jrnh2H+zA 23A4jzago9FJuf4b8d9DwVJsuVDy1DSotxOXAPf+lweR5K8kAdpl8mN9t6jaOR3kPwPD Efzjt2TmXOPy60JR3J8kyVX/6CViUSDSvxY0jOpjUR3pRQtleosFBCzqULSLht1RQReI SBbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lca.pw header.s=google header.b=tGMBSHPM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o7si13679622plk.215.2019.04.08.07.07.53; Mon, 08 Apr 2019 07:08:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@lca.pw header.s=google header.b=tGMBSHPM; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726530AbfDHNRi (ORCPT + 99 others); Mon, 8 Apr 2019 09:17:38 -0400 Received: from mail-qt1-f193.google.com ([209.85.160.193]:39524 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725933AbfDHNRi (ORCPT ); Mon, 8 Apr 2019 09:17:38 -0400 Received: by mail-qt1-f193.google.com with SMTP id t28so15280495qte.6 for ; Mon, 08 Apr 2019 06:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=dQ1SL9x4bZEYJy4r8vMymO8S+vKZHanfiXAqd5yNVlg=; b=tGMBSHPMKldELijf7ebfUlxeeTeLrmGlAS+GT3x9k22hlFNOefudwLsOJx77cQ2zsU XC11xSxJvWxx/g+DvPTqp/8G4WASzymHnVaKllfPqqBmWkVewDkjRg7EUAwQ4BwMEnek C1qXrzW/ZIiP6VHcqJYgvhz1eim3v/0aGSLlNPyaN70cNdNdVJVZNAJnvr4nF06KISIM ScDscYVVw3QXzS7iMbLH7H38VkMo9hrotMWyQ0B16321feot7yXACtuM/YU6ounkokuP g5OGfx0I6eoOMS4dx9aOxSKDB1VWlkwNFdd3gzGRv3+7OkgRtm4tC1OHjeNCcPWX/Iql rfqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=dQ1SL9x4bZEYJy4r8vMymO8S+vKZHanfiXAqd5yNVlg=; b=kJb9wmpoMuwaCsC7FWBCJuPLH7egLWdZMtsX3yw3kH5p/PNqJOy7rUS7v+Jtz5I3Ai hsY5MHOYgbvKzltCDMVpWHEqMY11LZ0Hi7K20fOXsz2o10ssWgcJMpVaQs7G7siZTSxv /bSSt3CEvISMQLU492fXfNBsnwNKa9uBc+gHcSbN1iuoe/txnSm5KJaMfnOS66mkdFyu l7XdNelD4XFZFHqphNiMwnWAJFuNj8b6yqLck0TGk21ihDutxqwbU9XGWq3V+ro5vAFP s0sjUupn+g/owBhVdxL+PXCNJwuYpa52yGgc83ssVQOoGuEZzluGEmUvRWrGG4SRbRxq ZitA== X-Gm-Message-State: APjAAAXwrXy6WJZtzpeqV4QCnBxVO6O814T26iWTcs08oBhWcTiGNy5m w2BUb9a4VudTpxyChgVrfwQjWw== X-Received: by 2002:a0c:b78f:: with SMTP id l15mr23189216qve.160.1554729457052; Mon, 08 Apr 2019 06:17:37 -0700 (PDT) Received: from dhcp-41-57.bos.redhat.com (nat-pool-bos-t.redhat.com. [66.187.233.206]) by smtp.gmail.com with ESMTPSA id n70sm19984226qkn.5.2019.04.08.06.17.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 06:17:36 -0700 (PDT) Message-ID: <1554729454.26196.44.camel@lca.pw> Subject: Re: [PATCH] slab: fix a crash by reading /proc/slab_allocators From: Qian Cai To: Linus Torvalds Cc: Andrew Morton , Christoph Lameter , penberg@kernel.org, David Rientjes , iamjoonsoo.kim@lge.com, Tejun Heo , Linux-MM , Linux List Kernel Mailing Date: Mon, 08 Apr 2019 09:17:34 -0400 In-Reply-To: References: <20190406225901.35465-1-cai@lca.pw> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-10.el7) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2019-04-07 at 19:35 -1000, Linus Torvalds wrote: > On Sat, Apr 6, 2019 at 12:59 PM Qian Cai wrote: > > > > The commit 510ded33e075 ("slab: implement slab_root_caches list") > > changes the name of the list node within "struct kmem_cache" from > > "list" to "root_caches_node", but leaks_show() still use the "list" > > which causes a crash when reading /proc/slab_allocators. > > The patch does seem to be correct, and I have applied it. > > However, it does strike me that apparently this wasn't caught for two > years. Which makes me wonder whether we should (once again) discuss > just removing SLAB entirely, or at least removing the > /proc/slab_allocators file. Apparently it has never been used in the > last two years. At some point a "this can't have worked if  anybody > ever tried to use it" situation means that the code should likely be > excised. > > Qian, how did you end up noticing and debugging this? There are some nice texts for CONFIG_SLAB Kconfig written in 2007, "The regular slab allocator that is established and known to work well in all environments." "tricked" me into enabling it in a debug kernel for running testing where LTP proc01 test case (read all files in procfs) would usually trigger the crash (Sometimes, "cat /proc/slab_allocators" would just end up printing nothing). Normally, all those debug kernels would use CONFIG_KASAN which would set CONFIG_DEBUG_SLAB=n. However, there is no KASAN for powerpc yet, so it selects CONFIG_DEBUG_SLAB=y there, and then the testing found the issue.