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 3094DC636D4 for ; Fri, 10 Feb 2023 22:05:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4400280031; Fri, 10 Feb 2023 17:05:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AF3F328002F; Fri, 10 Feb 2023 17:05:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9BC19280031; Fri, 10 Feb 2023 17:05:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 89C4C28002F for ; Fri, 10 Feb 2023 17:05:14 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 557CFC0659 for ; Fri, 10 Feb 2023 22:05:14 +0000 (UTC) X-FDA: 80452763748.28.64B9D5E Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf14.hostedemail.com (Postfix) with ESMTP id 82DBB100027 for ; Fri, 10 Feb 2023 22:05:12 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=dy+dvguF; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676066712; a=rsa-sha256; cv=none; b=OPR9HDOiD/pLQiP8ZW1P2fFur5aJbFOA3FEl58jwfBQLfY4bDiV8pfmEFyR/DxQlpkoqfJ CgroaMtiNzq5lTGl/Brp1Pmqoj5YvLe18afPoZ0kryu4JdlWulYAishRckTJGtAZjeS/F2 DjzpZGUybvfqoZLjdCIG/N49qnx/rLA= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=dy+dvguF; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676066712; 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=v/VojwKM7QS/T97Wn95H5cQElax6tjipq+/IW86+wEI=; b=l7PZt+k0sSgcANH+GHfrLHBvMfNqHMDmxNjpQ9dA277l+s3VR1mmYwImTsKgVZcL3lOC4y qvpqt6Y18RyQKT+pztMPTwXx/W4TUNb6yPJLeL8mFtL5NrEiWVVChWz8SgA9lnimQrjm/q iBTir2YQwBFdtpHiF6DIgIoB49eMbhI= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id EA442B825DB; Fri, 10 Feb 2023 22:05:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58A6AC433D2; Fri, 10 Feb 2023 22:05:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1676066709; bh=2jI798peCr/hq7cFnru4WZKXOiO7n+sEsxPR1h/PnrU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=dy+dvguFgD+ztvxJGXZWKJ+A9c8JhoCa3DyaXl4QxX+P0fj/yE7KboId03NdyPbZ/ 2sV/gpcbrGc7iQMypxswrUjh7Qp9vvT/bCRfykGxE/LY9WvL1vB8WWxAI+LY3lWdry s0fKEYhyvpysntNsENcMF/WScrqw71WCnC5CEIJE= Date: Fri, 10 Feb 2023 14:05:08 -0800 From: Andrew Morton To: Yafang Shao Cc: linux-mm@kvack.org, Dennis Zhou , Tejun Heo , Christoph Lameter , Roman Gushchin , Vasily Averin Subject: Re: [PATCH -mm] mm: percpu: fix incorrect size in pcpu_obj_full_size() Message-Id: <20230210140508.cfafb571dd44cf4fe776750b@linux-foundation.org> In-Reply-To: <20230210154947.4460-1-laoar.shao@gmail.com> References: <20230210154947.4460-1-laoar.shao@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 82DBB100027 X-Rspamd-Server: rspam01 X-Stat-Signature: r3o9yy6tgeghyd99wityphyww819fdp1 X-HE-Tag: 1676066712-767678 X-HE-Meta: U2FsdGVkX1/dWZ2i18UfDUlCHOUnuvk982oTt7wGt703ZCFVh8+wHL1y77uhCSRy+aL/dKDs88wvHHVS9IzgFqtJb/gj7oKGqkOgQc19ug+n2nKe2N74TTN1gpjw0vY+uSA5F81U2gBZ7voG4LurkXTtw1hgeUBtLF3EwLXh0WwQ/gNRQLMLLp8JtE4dQVFhqJ2Q3DsYpfl1uIfhWbHu1LTwiAnEOKLK2DZgN/ltQqdOHEA6vWA1pEhQMzkNBUrghj6upoB9lU9yhhs1Ubl7P0dOBpm9TBPT0jdngZAZmTDgpDizvgC/0n1MdZZkVT2qd39b15W6/qcJ9rLJRSTSVloBmuJhB5aRgqeiGatRhksw+c9JOOOZ2RmGyz5VfKWTZDNtDt2IRcuDLGFVd6Q/aDnPb33p3p0/GrHc6gNffO66hUscJhFQq51K99tJegdi7fN9fSmoJMlJKKQKJGOslOxiCzCJsgpckYaVkEysPBpJhDcqrY4RZZsu/letulRfkyKS8553UNWQhmFjWqtMiOV37zMwceXHP/LrtlUxTpMdWDX90zDuDlj9Iu6fvbNYtZzjS/p8UGv17hz/crwj0Umjb/D2/lYM43pdbJnuWB8yCRFeuUKHg2F2WbQOJS0tgHivl3kr0nByHBtSD40l7m6LHxQ/MxAokXSQACR4gTNx+w0v4RoFBpIYAKLLGchhdXfrNViJ4f6vvqic04P4ELX1cUbuz8R7xIG4O/Wx4XBByNZrVGh9jduKHEAbd/kQAFL0gX0mtnselKnZO5lQ1jNjnjCgfC1kFjyj2FAgf4ktWAnDK+59599KBibqzgg9zfqoLUWtc5wSae0QxyZ2LAjjrDgbG/0dJvzPdLdDWa2jz+7ThFioYhj/8pTFcEeI7xh4Mhnk35t1Gp2Bic9vreYY5q141BmLZPpOidTld1B9YhwYgKNZoALjLJhCuAhl8E7CV9zhNFma03mhCUh 1Keom2xf 4qCKfNJyhPwMDXblumPEJz3uYXmuLtInUR+6z+sOGIQQUOjlaAMXkg3QbOAN07b3mv/i8onIkw+o9aGyhMIQvSvEzDl9VI8jeC9QrNtyYLeUwRTGx5pixFBqIWC3uplZdgAFFKnxum7A+Qlr9+sm4KglE32bdLI21T1jyc/Vzva2Ap+ZUpCR237QIBkUAGeajpUqGGgUL7VPDAKIxS1N2zdU1v25S+nVYwkcjmQap/DmG9/lXhHwB5GrjNGO6f5jsEWT7E1mQfD/yj41LFhX8NWupPwf6nFEKDJtvqamNlHE//n147rwjffW9QFiRk8vU0sjoDhChN7cAlZ5IeEkPJujRte/2f66Ddwrzb9g0LPCJF1lwqwqgWcE9akUFLkrEGMf0Qf6EuLCgUUajbt6NphNMn/7GoBMuNsAOqnWknXrT7zgvIqK4xxX9sydxNkpres3OFMvkAeCAoIhWzNTbRZEeIPNWK1lEJGy2iwBeqf/MTFkZFUvBXvwXDnP6pLV3TLSxI37Oz/KGlf0= 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: On Fri, 10 Feb 2023 15:49:47 +0000 Yafang Shao wrote: > The extra space which is used to store the obj_cgroup membership is only > valid when kmemcg is enabled. The kmemcg can be disabled via the kernel > parameter "cgroup.memory=nokmem" at runtime. > This helper is also used in non-memcg code, for example the tracepoint, > so we should fix it. > > It was found by code review when I was implementing bpf memory usage[1]. > No real issue happens in production environment. > > ... > > --- a/mm/percpu-internal.h > +++ b/mm/percpu-internal.h > @@ -4,6 +4,7 @@ > > #include > #include > +#include > > /* > * pcpu_block_md is the metadata block struct. > @@ -125,7 +126,8 @@ static inline size_t pcpu_obj_full_size(size_t size) > size_t extra_size = 0; > > #ifdef CONFIG_MEMCG_KMEM > - extra_size += size / PCPU_MIN_ALLOC_SIZE * sizeof(struct obj_cgroup *); > + if (!mem_cgroup_kmem_disabled()) > + extra_size += size / PCPU_MIN_ALLOC_SIZE * sizeof(struct obj_cgroup *); > #endif > > return size * num_possible_cpus() + extra_size; Seems risky at the first look - enabling kmemcg at runtime will make prior calculations based on pcpu_obj_full_size) incorrect. But as long as this is only used for accounting I guess that's OK. What happens if we do a bunch of allocations with kmemcg enabled, then disable kmemcg then free those allocations, or some such thing. Does the accounting end up wrong? The final sentence in the pcpu_obj_full_size() kerneldoc could do with an update - it still implies that the extra_size accounting is unconditional.