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 B429ACEBF81 for ; Fri, 27 Sep 2024 08:01:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4393E6B00B5; Fri, 27 Sep 2024 04:01:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E8996B00B6; Fri, 27 Sep 2024 04:01:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 289896B00B7; Fri, 27 Sep 2024 04:01:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 07FF66B00B5 for ; Fri, 27 Sep 2024 04:01:57 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7DC8912087C for ; Fri, 27 Sep 2024 08:01:56 +0000 (UTC) X-FDA: 82609774632.16.DA842A0 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf26.hostedemail.com (Postfix) with ESMTP id 8E44414001C for ; Fri, 27 Sep 2024 08:01:53 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QK+OlVnZ; spf=pass (imf26.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727424076; 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=bAiUwYJ/Yx1ucy+uKiljXXWCLKHLqRUsJizRfstrbhM=; b=f2fh8QuXf7o2uu09IkWRqmIEMrzbFro20IoNLpWhqEiCSp8ieO0GxIjZKibSkpY4pEt+rb v2o9l+D+BWqe9JnNi7Q6HdhV8YaxkTDX09/yqIanQ2nZ987oCzhNlxtFwI+lKSWTwl9Uzu vFk1E6Zzl4sh4E82vlRdjvbwT/EBfak= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QK+OlVnZ; spf=pass (imf26.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727424076; a=rsa-sha256; cv=none; b=oxjv9z8Z419wsnDbhOKySihoAATZUN1c8qGX1ytftbkKZLVs/t6B3oViPZGI3fSpUKKb9P EXto4UGBlbM2U+CrEpVGI7z/yiSYLehzj2BI2sn7h10tSmfWEWCJujUeC6tQG+yQpmaR0b aFxDxG4/ijsCaEDb4qQQAIfqMzGcI8I= Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-535dc4ec181so2008354e87.3 for ; Fri, 27 Sep 2024 01:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727424112; x=1728028912; 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=bAiUwYJ/Yx1ucy+uKiljXXWCLKHLqRUsJizRfstrbhM=; b=QK+OlVnZ2FYN8Sedq6X2Wr8oQe68lbednd72EfbwcG+HytvFVsF9OQ1G/phbMEDSv6 kJ6LkFud/vosPzHHu8LnLLi1vFrr3IAUvjWo8nnPkWGFZgrqJG08zXdHZM9vKozvmtqy jOaujjG3Y0aS9MTFXYOVjXbcUE/XALlbMuQTg/mFZBEZSn2qlGSnQuWSGhnpmSQYkfV3 U/YXIr5WETYD9jJPRB4C/B8vmUFxMK2zI6upMa7fcHB5wDjha19mG+goAl6Tjcg5LLLY OTY6O2qd6lVMJ0S4OxmL8zlSzViK74CPHEhUvR5JfJDqFDFaqSxiMVC2NotRGElnQfMx FCfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727424112; x=1728028912; 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=bAiUwYJ/Yx1ucy+uKiljXXWCLKHLqRUsJizRfstrbhM=; b=mvLAmaVr2RWDaerxJmK+sZb8B4BTLy11PswFQn4vNbS2dPl9mO7N7c4xxIGJGqPQ90 lea0/EqRKL/NIqrKjPYYW1HNwSHBBvIfCq1Fl2qGEsOh0Li1LLOCgsem6CwBdm9i5nqq TvJ++x4/+roASQ2HX2xQhIo6G9RHys6gpZAWGWYnR9RHW4ZAlWU9WitrAeG8upGUPWr3 1SuN4z/iooM+IhpfiCCazezrRSZKrtjn+AtoYcv0jBFCDWvUx5vGYxHBqpQFvu74BTCt Uqu3ku2XAYU07KGele01bxLjB9NfQg05gcF+L+/7UggL9hNYaVg2Q737cTuL65WxIH97 bF1A== X-Forwarded-Encrypted: i=1; AJvYcCXgKVFj3ahaGQ1NoiMMCHuO9BfZycY64FGRihtGWakbMvrLoIOrs1N2XooMbFdQoKuMs9j+j4I+Aw==@kvack.org X-Gm-Message-State: AOJu0YykQ3qSFJHS+zjQr7nJFVUVzcLKHwueC7wjUsCIwf4kkU7lAQox El0YmnHclLTt9bzMhWRf1d/Zr5e9ve2vi3gXmamRYiTRiAMjq/Pztw7wcL1f34N/yVIA+V8RiBb +TBqgqJyWAp+zY+AOThQaLQl14ONuElaerB8= X-Google-Smtp-Source: AGHT+IF3gTDoOAl8ED/kCjlLGzYhGVYfSJYOR9PbRAbCJBbw5yEqvqufsOyphpMrXh0wEm0uJHyf/q1fzh4469MYZAA= X-Received: by 2002:a05:6512:3f07:b0:536:54df:bffa with SMTP id 2adb3069b0e04-5389fc7fefemr1288020e87.45.1727424109957; Fri, 27 Sep 2024 01:01:49 -0700 (PDT) MIME-Version: 1.0 References: <20240925032256.1782-1-fangzheng.zhang@unisoc.com> In-Reply-To: From: Hyeonggon Yoo <42.hyeyoo@gmail.com> Date: Fri, 27 Sep 2024 17:01:37 +0900 Message-ID: Subject: Re: [PATCH 0/2] Introduce panic function when slub leaks To: zhang fangzheng Cc: Vlastimil Babka , Fangzheng Zhang , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Greg KH , linux-mm@kvack.org, linux-kernel@vger.kernel.org, tkjos@google.com, Yuming Han , Suren Baghdasaryan , Kent Overstreet Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: etzt7ig373r9fkn9na9yzi35u6ci7fxb X-Rspamd-Queue-Id: 8E44414001C X-Rspamd-Server: rspam11 X-HE-Tag: 1727424113-693564 X-HE-Meta: U2FsdGVkX18A07etOhHq2Nqj7v7I29d/24E5fmGAtbEychQYLmzs4cfH76mqgxZAhulbw8XPcG8OTXBsisKiQ4Qkjbftc58STSnPx+AKClnz3ikjgViYui1706TPVdLGGNGxTBUnXjioMk37lD+PYNoFzv+kS7LmakTYeOVhjVvIe7QegVXTQAMNYm9CL0nK9qKmd/PBsjARerTdIG38dFXGSB7crkfo5oWLT3Eof5dSgRuL5kTl9KWJxgvlMzfpMP4ZNzvqPzFsq9yIFCxOtF7kmoPz3c4syIZPqypeHQFsEFukDvKaZkIHUikSF0YfomWPU6Y2ncjJC13eTZ7+ucjisqKWvf2iH79CqFXOc20/KBVMAy/2/LC3PDnBmBm0pIPqXzDIYxT3xXj5AZne0XYzMx8fItSM88OV5XXfUQ9iyTjoXoxGc9kuP0ALpO4UlEo8Xfu9dYiJM2iF0aSLZsBVGROXkQakoTin4jQB0K8kKfDNW9m6lWkg+sTEMNZc2mlqxqwibAu9+PTvF1r7+eBr3QZWK6a9yRSCWpmPTA0+77MtrtJ6hDlHHBlhQqsl0xTxRsQCxNa2aq9pYnWVvAchKdbmmD5WxndFQIJR5ES7J8Bu1wSDCvEWYHQM3HicYODli8tTEmBtUdtZFrwHEXM6Ogudka55Q68W7JVzhb8rPJUKto9bRQvX0MKyPE7NPA+YxzT0EsogKIo4bhMDpHlfiuCSFSsukgiCDalfBD9OWqLloXz+nva9+Q7cZwh39fErSmS9o7gFpk+Ig/BWhos+5YEbk2CVsAFalld0kpjQ+EG9OX21fnCom//pE/BZfvwhh4GAimZlb3KdaFzR1DkcfD6B40z/fIfcRZBT2OLEJsBnbzD0rgJHbzbwQPV4eJnJP95aW0q6MzaZ44NwngQT9m5rhTZcWfzLXCoJiV2DZqwml6cZ7nKvb9Dl2Z+h3GOD8ifRAaSMU1UCZ+r ELjkMxn5 adJGo55sjsopogfpccPIKxxEGgl+AtI2uf27nOSKIPfqHvyfYKG/deo0VGueQuXV4kw/8w8F4jF+GXzVw9R4HS9nEeTkGxx7SydyFqN6ghhUL80lN5OiZP+wg35WuRtf6EYtvEv/nO5jjmO2oMdJdwcWB8GUuACt2oHFlyLuW3yc8FFEucDUp3jwgh/zT009GRmHChh9EuEBjWa6BHCg2bgFvAP0f42Ipf1tdjtyCMmLVArythbb0/Z9hUGKOFFLGo1vXR/RVCDHHe4B8bop0Pl+5JUxcf+cphY+KWK05cIZUkkdCWcEuMgp/tRdRNDJg9tsr6L3z23ARuzThznE2IKtzPIKCb7mYqkKCTXZznE+ac4FZnFvV5bfZliFaySQLXU6yV2ui73tvL0GWskDqKaZ3jbheLBiUiEsX/4zO5AreGp4ky7fpLwPDlwhwzo31RW7WCf18gmnk9nUXClgYPlPffPNzjzYui4TgsV+qD0KYKVo2kgYLUVOcg9tl9VcR57y5izn6gDYbLPAXmyIoMgwzEkJTbNN9BpJfdqMxsQIl7pmaONMtn+HVIEy1pVTnrlZCIr8RE8muwRHKIFgzX3hLSoUznsCsfioe 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 Fri, Sep 27, 2024 at 4:28=E2=80=AFPM zhang fangzheng wrote: > > On Thu, Sep 26, 2024 at 8:30=E2=80=AFPM Vlastimil Babka = wrote: > > > > On 9/25/24 15:18, Hyeonggon Yoo wrote: > > > On Wed, Sep 25, 2024 at 12:23=E2=80=AFPM Fangzheng Zhang > > > wrote: > > >> > > >> Hi all, > > > > > > Hi Fangzheng, > > > > > >> A method to detect slub leaks by monitoring its usage in real time > > >> on the page allocation path of the slub. When the slub occupancy > > >> exceeds the user-set value, it is considered that the slub is leakin= g > > >> at this time > > > > > > I'm not sure why this should be a kernel feature. Why not write a use= r > > > script that parses > > > MemTotal: and Slab: part of /proc/meminfo file and generates a log > > > entry or an alarm? > > > > Yes very much agreed. It seems rather arbitrary. Why slab, why not any = other > > kernel-specific counter in /proc/meminfo? Why include NR_SLAB_RECLAIMAB= LE_B > > when that's used by caches with shrinkers? > > Ok, this is because the current consideration is to specifically > track the memory usage of the slab module. > In the stability test, ie, monkey test, > the anr or reboot problem occurs, there is a high probability > that the slab occupancy is high when it comes to memory analysis. > In addition to directly monitoring leaks in the allocation path, it is > also convenient to record the allocation stack information > when an exception occurs. [+Cc Memory Allocation Profiling maintainers] For recording allocation information, I think CONFIG_MEM_ALLOC_PROFILING [1= ] [2] may be used to track allocation sites that contribute to memory leaks, instead of making the kernel panic or printing WARNING? .....Or with higher overhead, slub_debug=3DU [3] if it is not meant to be run on production. [1] https://docs.kernel.org/mm/allocation-profiling.html [2] https://lwn.net/Articles/974380 [3] https://docs.kernel.org/mm/slub.html#debugfs-files-for-slub Best, Hyeonggon > > A userspace solution should be straightforward and universal - easily > > configurable for different scenarios. > > > > >> and a panic operation will be triggered immediately. > > > > > > I don't think it would be a good idea to panic unnecessarily. > > > IMO it is not proper to panic when the kernel can still run. > > > > Yes these days it's practically impossible to add a BUG_ON() for more > > serious conditions than this. > > > > Please don't post new versions addressing specific implementation detai= ls > > until this fundamental issue is addressed. > > > > Thanks, > > Vlastimil > > > > > Any thoughts? > > > > > > Thanks, > > > Hyeonggon > >