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 64F4EC636D7 for ; Fri, 10 Feb 2023 22:39:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DC1286B0204; Fri, 10 Feb 2023 17:39:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D71FE6B0206; Fri, 10 Feb 2023 17:39:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C39B76B0207; Fri, 10 Feb 2023 17:39:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B084E6B0204 for ; Fri, 10 Feb 2023 17:39:56 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 789D7809B2 for ; Fri, 10 Feb 2023 22:39:56 +0000 (UTC) X-FDA: 80452851192.28.9223796 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by imf29.hostedemail.com (Postfix) with ESMTP id 9AE5312000F for ; Fri, 10 Feb 2023 22:39:54 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of dennisszhou@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=dennisszhou@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676068794; 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: in-reply-to:in-reply-to:references:references; bh=Dszl0U/L2p4pBuaeci9Tw/Fl8YXmCPI6+ar7DO9Ph3E=; b=fynmGk69rK+Zgzs/FbbjjxXve8kXPKh6GyhhuacFPGWOvUfFyp54OJUWNipWolSlrhDWvn D91K8iI8VMcS2DTBWK55zCKsMjcZIgjPST9DQZvycdIPyQG6RUhQKR+JT2obs5lxxYyewC Sn08UxXmLBsQESs53Ynv3QECwMYGzoM= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of dennisszhou@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=dennisszhou@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676068794; a=rsa-sha256; cv=none; b=a/6+NVOVJqJC/xzPwCchUvCq4Vvl/pd3kpsDIdv96Y9V05aUCC10mCWVaFbBDiv1EavJRV M7YlTOw2Jq54WMvCYK254BSCTvMVOaPHaW7/1OIV8+DDhHOwb5DIjqCJZ172Gw/co34Xae jZOgSK5LWL/pAH++cqbC5WyMlF3g2UQ= Received: by mail-pj1-f53.google.com with SMTP id e10-20020a17090a630a00b0022bedd66e6dso11588693pjj.1 for ; Fri, 10 Feb 2023 14:39:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Dszl0U/L2p4pBuaeci9Tw/Fl8YXmCPI6+ar7DO9Ph3E=; b=fbmJMdfj3mvAnS10/3wZ50rphAY1LeK8L8O+73CU+aOQ5Nsd/10ANCFs6TGNu/Vmi7 +9zM/RwEz4TnFinLo1ywkRa1Pel0tbAJJ4BElmGof2JFW/Qy3rhZCzrabBjkf1xqHKNI B7KXEByuq7Lj1eOknWxTY9OyfolGpntFgzZ0wi1/vtLPCQI7TzP+j/Mz5B9tW+JViWvj R8Fpoqsl8MTlAs6l1F66QeATRX6WXEzdWGfgd17cQAIpbQm7FA4HMD8Ba1N1k6BFaoAf r7V3plXKqXsa7NOv5VwIPb7B8QY9hKKRN8uPkUa8XxhAGjpFFgMcUyJ/qoeirGcVO4T9 n88A== X-Gm-Message-State: AO0yUKVWwI1+zIMEDbhiR7vk8XK44vmYcnsaO2KAOHG93Lu5HNx2dv1i eCmpt4191STGsE9Pcb0QRKc= X-Google-Smtp-Source: AK7set9IHLHX3+1V7sb2sFH5aj7jz7g0BAJwiZaBIJLmQT2sMr+I7YCsND/qZBtFVRdARHQsN6mdNA== X-Received: by 2002:a17:902:b10b:b0:198:ec00:81bb with SMTP id q11-20020a170902b10b00b00198ec0081bbmr12221110plr.53.1676068793389; Fri, 10 Feb 2023 14:39:53 -0800 (PST) Received: from fedora (136-24-99-118.cab.webpass.net. [136.24.99.118]) by smtp.gmail.com with ESMTPSA id p6-20020a170903248600b0019949fd956bsm3826575plw.178.2023.02.10.14.39.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Feb 2023 14:39:52 -0800 (PST) Date: Fri, 10 Feb 2023 14:39:50 -0800 From: Dennis Zhou To: Andrew Morton Cc: Yafang Shao , linux-mm@kvack.org, Tejun Heo , Christoph Lameter , Roman Gushchin , Vasily Averin Subject: Re: [PATCH -mm] mm: percpu: fix incorrect size in pcpu_obj_full_size() Message-ID: References: <20230210154947.4460-1-laoar.shao@gmail.com> <20230210140508.cfafb571dd44cf4fe776750b@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230210140508.cfafb571dd44cf4fe776750b@linux-foundation.org> X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: euhfgb8hsim5qu6zsbr47q68fmckiqgc X-Rspamd-Queue-Id: 9AE5312000F X-HE-Tag: 1676068794-59238 X-HE-Meta: U2FsdGVkX1+hnAWyh8XtRxesAkJbRGnekrgGCoOwjej150/YEYj53DJpZonB67U2ZXIKsmsY3crUdpXND/QtZhBRoMw1rv+vazzx1Lt/qr2lUrrT9nCFvv46nu13B69hq6k7k6+g8yjQWAFD7PBNHXjuZDV7d5+zZPUWMBQyPnp7r4ktRZyj8xTb3paZWrN32jhvpl00It2Ht97BsVZqrlabkYg01Hyulhf/GgPax2xO0vfm7HWqHbVBEvVg6jUtEUIlJqUupdkGq6TVOVKZxJMucdMeoQ2+/ic67SJq90+qUrkRO/rZBhkRk90UM/b7FmHsddsECmo5rlxZLXmlm0/KfItzowc6+6FL41YQ6BM1ajSVcdDQmWS05UW1q51SOealmGsk2j3PUliNfDnSPLEu7D5eGIkiVAAvW6JBFski+cnV+T9aPVd6VvrrW5RwtCIsxlLwfNbcPF8BrnsMZHVrIn3lU/LKkpGalVSanyGKScSQvUwNxCe4I7fW2R+npPfqSZgIh8GouoU6jJ6xLeE62ijcKeCb4cHTEimQ9f6ZDMlT47+A3CTVcKciBDPsUNX38KlA2XS8nlib8aMTKJXqwNH2Pvv+0KOQB+B7bIkzp2D2mM/CUF7x+PYFZ3eB6rpwpc1aRzCYjZmqHuAW7uoc/GYi+7aXCDL9PuZyzq/zEb7G//ChgnzIx5FhCsGUc0Sd7/4zs6meFQQMqMjbqnUvi+ZF1+CcPSKu87v+Lvevbxfv59J3/hZmVcRiQaBzv+kZXbFwwP8lTa4CbIurops/5e8eyaNdTNlZ+z3QqWnV+e5kmy9p05mVyIVQ5naQsa7iwZLR6JjoX6IW4aC5XMC34OJtnNuOPaX0+KpcH8Wemo5B1MiuWGwzd67nH8vupsuL4sKuMnCcw2d2dKHR0yAKMd/43JlHS1vX9P2dXhGWZROnPv4wip2bWoNNDNtcxc/9eyJ+KpqAvNkUIVl oABw+ZcP me4fzqjvEyFLev5Ke97gNjqf6INuxqCkZQEfBo88x50K08JEXHjx0l0V0/PRg24ZumvSvmBjxSiz7bFzSNVpX2DKFPLaIzXujI6E0+NGNEMRV5+ytE4w2iSJTI8Ucn+Krm/Fk9IijiVH2uokplwFI22ImL67U9UjOv5gssn4DcY+CE0k7O9ReEqjhh/dTnz48yCb9Xdqaz+xkR56M3XiZXMmFjJF80htLuWYi/KzVoMU4zaEP354yMaccfTTJT3J1toOBGTGyT0MLjoGP0lwTS8KvExPx5CuThjb3QbjHmew5I/uBWZ6VTk3MeFb56BC5iA/gCf1cTktos0//UhklvmCy61bdZ2XY3D39rwwqzWH6KKp2ce62wwpxONHMQkvH7VlaC73X4/FyXZ+XvH7G34x9M8xi706cCXg6PHhHYkjjgL+donOxFE0dV6mDm/07hRjaxKlDM07/mQnUawyneIPzPLIvEt8ON9YUtBTRKQKfwJ0381v88f3VshGso5w7RZNOnqh175JwX/X6eXfpbYDQumxJzIw0I0MU0fDziuemhYt8LWpWycMHZrLtnLhfg00sV33mjbMtd/vwccynzuDNMmATulG+/SgGEoCeMXDIskkgqvo7lyTsmBwDxMsZ07myHBGNdOWxJ/XjgIBSosqtfizIAHaZozCw 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: Hello, On Fri, Feb 10, 2023 at 02:05:08PM -0800, Andrew Morton wrote: > 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; > Sorry I've been a bit mia... > 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? > For now it works correctly because of 2 things. 1 - the function is only called by accounting. 2 - the free path doesn't consult mem_cgroup_kmem_disabled() but consults if a memcg exists for a percpu allocation. If accounting is enabled, we'd always account the additional memory for the memcg accounting. If it's not enabled, then percpu is well unaccounted for. This function probably needs to be renamed a bit more carefully so it doesn't bleed outside of mm/percpu.c. In short, I don't think this change is correct. > 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. > Thanks, Dennis