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 1B652C636D3 for ; Sun, 12 Feb 2023 14:06:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 218D86B0073; Sun, 12 Feb 2023 09:06:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C7F46B0074; Sun, 12 Feb 2023 09:06:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0917D6B0075; Sun, 12 Feb 2023 09:06:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EA4816B0073 for ; Sun, 12 Feb 2023 09:06:20 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C27B21A0A39 for ; Sun, 12 Feb 2023 14:06:20 +0000 (UTC) X-FDA: 80458814520.10.13CA872 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf03.hostedemail.com (Postfix) with ESMTP id 1FCAE20008 for ; Sun, 12 Feb 2023 14:06:18 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YgFIi1Qa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676210779; 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:dkim-signature; bh=uovifrqCS0IMxKQpOoBPYHiVcteHSnqbhdpTsNzJFVs=; b=4H/I7h2zQbp9vdfhams0qVt7yeP51KPxGRxhoE8iyM0YpsbcT6+6aMwYUNJM6nTCCHzrlQ N84l+jcIx+0WeCspiUN4GM0XFOfl2XWR9RKIjYi4giLKC0qOqzKKNStsJgGE/SXMAgfKO5 UxyWgcwQGH/sJ1KrM26wTC9AORM0eYA= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YgFIi1Qa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676210779; a=rsa-sha256; cv=none; b=GKCkiq9trSQlhwrubuXFtj9FyGmoVDahIiy4Po+Lyc0vdffB25nE+xWdbtkJE6ecP6GH7P o3cLTUb3Me6PGt4P3zA3PpOogSyQszDO+S/34x5qKZqu4XCmHdkIv4To0/U6y7+PtL9l5+ Gx+RjvJG43VWnwcWEWIOG+/9t06+hjo= Received: by mail-qt1-f173.google.com with SMTP id q13so11189799qtx.2 for ; Sun, 12 Feb 2023 06:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uovifrqCS0IMxKQpOoBPYHiVcteHSnqbhdpTsNzJFVs=; b=YgFIi1QaT+hbleEIYNjRWdh2/5oZ64f5r4Rj9siaVQA6LUerxPpx/Or9YStzrvFnA2 nGbzOec8M06klKSQfdtydlZM0sACXvL9FPPTlmkFBzXvkmnVri7TxBmEY9ZMBX/VB7ma Kun9NmVwj2558BN+AxoFQjdgJoCpT1JzjdvDDipXcc+vC6Zp77HSgz2qzcf77ld9kxAj h+mRR+onNpBdWwhqt7p2YF0nevQaijEa3x9hIajwvvuf8XSIesz8XJXNJvECT2dMiJbR ItYqLUm2ulcWX1ZApCszUOAckCmaO5wnDIN4lBnH8kJLxpdplAfmrvGfyQ62lVG5lQtL s+UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=uovifrqCS0IMxKQpOoBPYHiVcteHSnqbhdpTsNzJFVs=; b=eD5hSNdRnAp6ExGtjKmix6HzJWy5+7Af6MXH+/9Euq9rmDhCmxx+rKdaIsa/BQWVXX MmJ6jsAAJWaNiJn1V2Y8BtkXQT8bemv9/5saZP0aYoccUmnrg3vB3uEcQOzBb1puSLkd JeEuI7xhuIi9ZXAaYSPqDPtPC38aH3JV1NPnAJW++7quPcQxbuP4jUbez3Xg6LiN87/2 A+UNs97fBXYNLn8rBelVsHm1h9jZSp6YF8MPU1K9d8eMg5KA4f86GmsZqxUncZiLqodJ 7KRjFTDq9LR27pWKBrP8YJfJXdNBUxORDIZ104ZAf38gPoEZq1oNth/legxnTpk7nzMo MK8A== X-Gm-Message-State: AO0yUKVXPxnIqx8SQ93Ll9g6Zyj+U9MmFwiDAa8lofR77N6xg/06mgeh ZC++MmJ2JQgfl2Edvf3k1kkocU5tIuDLrCBTjak= X-Google-Smtp-Source: AK7set+s4C5oqmM7PKe4bgwWqZoq9ohm3tEo/QXqrEqpQGA5KpXz89nvoPBR9eQLue2GIJt5y0JfCGj4Q3ZIfU4ovuI= X-Received: by 2002:a05:622a:1a1b:b0:3b8:6ceb:ada9 with SMTP id f27-20020a05622a1a1b00b003b86cebada9mr2944340qtb.98.1676210778225; Sun, 12 Feb 2023 06:06:18 -0800 (PST) MIME-Version: 1.0 References: <20230210154947.4460-1-laoar.shao@gmail.com> <20230210140508.cfafb571dd44cf4fe776750b@linux-foundation.org> In-Reply-To: <20230210140508.cfafb571dd44cf4fe776750b@linux-foundation.org> From: Yafang Shao Date: Sun, 12 Feb 2023 22:05:42 +0800 Message-ID: Subject: Re: [PATCH -mm] mm: percpu: fix incorrect size in pcpu_obj_full_size() To: Andrew Morton Cc: linux-mm@kvack.org, Dennis Zhou , Tejun Heo , Christoph Lameter , Roman Gushchin , Vasily Averin Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 1FCAE20008 X-Stat-Signature: w76o8uotcs9k73izxm3xyzs796b1wmbc X-HE-Tag: 1676210778-621751 X-HE-Meta: U2FsdGVkX19RTAokAzEQqPonUilIqx7SzfnNcCFmI3k8Ux4KGEBlM5DOeK28xGiQQlGg2/b2P2OjqVyqF7S0Lf0j6LpsKsfQ65iH6WrmuU/n83R0PUmntOh1SqKwK3t3MJXi7Xxmbuamv+volnVuWbTs+ixKabs07k1lBzS5mC1OUxeCoTO1pfqwVwTl5gwwb+CnTDf2370fOvpsB39Pt6lXYgykAKG0GXiVm0uZqEJjgBFdJmIzJmYVLCUjnrlvKzNjGkPTRP8qC4x4Q39kpO987+f1CVlEDZq0XnkSfWbdf9RFzC2j+/M0LARJwxX6C4BVXvNOChLqiAYFISZ4AS2WHpobUJc7Sh7cPkenPudWIrNy49Hs9DNiQgZSGzc1eUA0GpatkpMjnSwkNpNCiQNatRgfGjjP8hlMDv5ccdnybKQ6BxrGl3CMj3YhYXDtjp0Wf7n11whK7NCXiI36btqynaDar2OpqpH6FbBQVKOWHwqPy5O2JhPu57lIChWSLdXIsA0mLNZRtY5lNZWYnLY4UluA7dr8tzll+/DdMaQCHBr50/cVHYmiCCcqIiKiR5Ox/JHPZJeCI8jYLu/PIl0Qk765z6Ff9KjNMFND7NyyRKbXgSVUMmnjaUvadxi1KfnGxyGDtE5gqK1JmzWCVjnbJl2KkpvnSEYtqJ2zPvgn/sDEZJVkv+r7IH4zyZDa7J+TOYqFhAH2H2Ko6oQ3ZNqcXhQT4B1PjTNwbf0SrVbvC1+UqVJXQji9YiIOu0H9NH0fD9WOyJe0p2fY8Qj9vVtL+NsNdhXspIv/zvZ/ItpUs+isT/0SDAvxGhZCrGzEJwF6TUM3ZiAhchnp9ReBSHtUkZUBEaSGA+zTg9qdwNtvKFh/Xbvx1KPRVq6amNQ0X3zs39Z+v1OUWW8C7HRwPxe+uXrgxfb2AAD+Xxl20S9+B6x3B1rtge7rHcdErkJ8dTWBuC5n9KJFaXOHy2U 3o7+jRV9 EdihJ01hL8L/gugte7E5yO/QDPkrWjDxgd/eBbShxIFvRvr9gF9KqEOOhqzpf04fGqfyMnXakAhxnql16HBuC4z+uQMrad4B57DMJRFLJY9Pxo/2If3BxYegQ10BiE06QEvwkDTYdl0slg77XmEh/6efEFBND7ht2xeWRwHmEb9boSUkHFdIajsS5m7wFeoziStyfRMzYY50IMV2tmw3GEiV2/JU3k80o8pGkpbcSX3y9QazDEnR6yJ/ouYjXFOgXdftm2rDzZzLiTqAYvdV5tnhw8Br7vXQhr2T6A7tZZvOMZvTSFdtFjkePB9LWdV0W9eH53j25ofStq/ey6Uqq++L+Gq7To9lmIiV+Oy6Gis/KvyM0Vre60lObh5DnM7TLwXHd3c83sQ/Ah/xyUNXHhHmlakgtb0qVEWp+eVAsJQPLH4fBGF8lxcFW5TOiyuWvDiyuKAIZ36vROSIn6Yrd3ugK0RZKFZcFxelimemO/Kdud5vTVe1XENDRwqHLNryg4PAd4DrVlB6NiX3hSNGwjadbLQ== 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 Sat, Feb 11, 2023 at 6:05 AM 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; > > 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? > That won't happen, because we can only enable and disable kmemcg at boot time. > 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. > Sure. -- Regards Yafang