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 AA1A9C19F2D for ; Sun, 14 Aug 2022 02:36:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7CF56B0073; Sat, 13 Aug 2022 22:36:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A2AF98E0002; Sat, 13 Aug 2022 22:36:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F3258E0001; Sat, 13 Aug 2022 22:36:30 -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 7FE936B0073 for ; Sat, 13 Aug 2022 22:36:30 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 492C8A021A for ; Sun, 14 Aug 2022 02:36:30 +0000 (UTC) X-FDA: 79796634540.04.F9A6CDE Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by imf16.hostedemail.com (Postfix) with ESMTP id EA16118019F for ; Sun, 14 Aug 2022 02:36:29 +0000 (UTC) Received: by mail-vs1-f52.google.com with SMTP id v128so4313001vsb.10 for ; Sat, 13 Aug 2022 19:36:29 -0700 (PDT) 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; bh=CRrhz0BEyIQHXQS7Ebb+dZKjXFqlcQTdj6VUIrrnwgc=; b=ftDvrBkguzbQ/2XyYFCtxaMeZSyG6ASkh0ukfmZpJkaUjIurT935qNLWskNEagEKUO eAhSQQ6MHAEjrmmb753yJmoPqgV4BUf55SDaE0mvKMoLnNLqO2+/+b3eprUZmFPPOJB7 aRuCEGm0YL9t4M65uUCjHNhf/quKNJmjuZqfPvTL+EJO16D7I3f4tJbHEI4A0oNT7aMA 16sWo4E3+a6uMqMV71ED17WRM71pYSMy+BoUoGfaBjzZn6YIqMfV5me1MASAjIxzcTZe uCYosMs/l7zv8Qri8c6fXcQWHn/z9EzE647USr1P/kYs8jwB0wBu41gtYg2X5FP8lRSv YQ8A== 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; bh=CRrhz0BEyIQHXQS7Ebb+dZKjXFqlcQTdj6VUIrrnwgc=; b=FW0Hzfxjq3b86ymr1EVLRQ3m1gVgDtrGeR+wVk3oj+fLet2oKShO6/y33cyYEV5WBM QYGirmlKw2bTO7UtV+548HKn6jnO4hbnzgUm/kAh6F4mZs7ijWejphWM9KZqxRB6UT6h 5u/dhpIAecvWx9QwU+M/7/AzJU7sdInA1vwa1ekzZDHCURUMhNGIpbA9XdTYFd2CJCBI GtmkAlccKViWjnMNIvC5tiWaaTcmNQKJgkIKG2/QkiKcZmxwH7b1Vgx9UcTjRNKD8aWB ErcLxoL6D6M4Jw30SlLJF95DNj9LjOOpFaOKlEraBpD1A0ndEqPJOfCBWQvMxjiAuC+v kWGA== X-Gm-Message-State: ACgBeo1QF+a7UBdC4uj504I4PL3LqLukNB6CLgPLcoaUCgX7MB6UkS8f 8SFvhq5lB8/C8HW/MQJ1bH4eIckbA3VzVnPRMpY= X-Google-Smtp-Source: AA6agR6xP+37xYYP/oJC40vFFtEp6SLwnBUAkGWFgSWjlaZv0tT4Jc+Drnc7QA0/YU0vEzbn/ZuaQfUQGqoPH65fG+U= X-Received: by 2002:a05:6102:2753:b0:38a:a86f:6ac5 with SMTP id p19-20020a056102275300b0038aa86f6ac5mr3471172vsu.80.1660444589209; Sat, 13 Aug 2022 19:36:29 -0700 (PDT) MIME-Version: 1.0 References: <20220810151840.16394-1-laoar.shao@gmail.com> <20220810151840.16394-14-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Sun, 14 Aug 2022 10:35:52 +0800 Message-ID: Subject: Re: [PATCH bpf-next 13/15] mm, memcg: Add new helper get_obj_cgroup_from_cgroup To: Roman Gushchin Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin Lau , Song Liu , Yonghong Song , john fastabend , KP Singh , Stanislav Fomichev , Hao Luo , jolsa@kernel.org, Johannes Weiner , Michal Hocko , Shakeel Butt , Muchun Song , Andrew Morton , netdev , bpf , Linux MM Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660444590; a=rsa-sha256; cv=none; b=11rxctexK53M8GgV+y8pVIGX3m7vqgVWQXfFeyf3w74n2lY+4wRTLWG56j5ppR5PPu0C8H Z2COEAXIdummhvbZWtmWO2uGLFM3TpdhxKYhK69tjqO4LSJalFv2LYvB3i6yU0H4YuHu/H npMm8lhHKYZUk1tuRz4TSMoiLPsZMrM= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ftDvrBkg; spf=pass (imf16.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=laoar.shao@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=1660444590; 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=CRrhz0BEyIQHXQS7Ebb+dZKjXFqlcQTdj6VUIrrnwgc=; b=0HLa1uMsTVOFA3QD5z9ogJNirBO6qfpSEq2FB1eavlPb7I0miJWNCn0RxROoc6QSZcD8HJ A7KFOHoXTv34q0odzmEGavruGGL8mI3iFIZCQPf5P+l90sHPt1vaG/C687vtC2EW8Sfcai pdflRJybGRVIH2NNKs5LbHrahz1ubI8= X-Rspamd-Queue-Id: EA16118019F Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ftDvrBkg; spf=pass (imf16.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: 6kb9xaemfw16zt9ts3b8s87duiam7tdi X-HE-Tag: 1660444589-984829 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 Sun, Aug 14, 2022 at 2:30 AM Roman Gushchin wrote: > > On Sat, Aug 13, 2022 at 07:56:54AM +0800, Yafang Shao wrote: > > On Sat, Aug 13, 2022 at 1:40 AM Roman Gushchin wrote: > > > > > > On Fri, Aug 12, 2022 at 08:35:19AM +0800, Yafang Shao wrote: > > > > On Fri, Aug 12, 2022 at 12:16 AM Roman Gushchin > > > > wrote: > > > > > > > > > > On Wed, Aug 10, 2022 at 03:18:38PM +0000, Yafang Shao wrote: > > > > > > Introduce new helper get_obj_cgroup_from_cgroup() to get obj_cgroup from > > > > > > a specific cgroup. > > > > > > > > > > > > Signed-off-by: Yafang Shao > > > > > > --- > > > > > > include/linux/memcontrol.h | 1 + > > > > > > mm/memcontrol.c | 41 +++++++++++++++++++++++++++++++++++++++++ > > > > > > 2 files changed, 42 insertions(+) > > > > > > > > > > > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > > > > > > index 2f0a611..901a921 100644 > > > > > > --- a/include/linux/memcontrol.h > > > > > > +++ b/include/linux/memcontrol.h > > > > > > @@ -1713,6 +1713,7 @@ static inline void set_shrinker_bit(struct mem_cgroup *memcg, > > > > > > int __memcg_kmem_charge_page(struct page *page, gfp_t gfp, int order); > > > > > > void __memcg_kmem_uncharge_page(struct page *page, int order); > > > > > > > > > > > > +struct obj_cgroup *get_obj_cgroup_from_cgroup(struct cgroup *cgrp); > > > > > > struct obj_cgroup *get_obj_cgroup_from_current(void); > > > > > > struct obj_cgroup *get_obj_cgroup_from_page(struct page *page); > > > > > > > > > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > > > > > index 618c366..762cffa 100644 > > > > > > --- a/mm/memcontrol.c > > > > > > +++ b/mm/memcontrol.c > > > > > > @@ -2908,6 +2908,47 @@ static struct obj_cgroup *__get_obj_cgroup_from_memcg(struct mem_cgroup *memcg) > > > > > > return objcg; > > > > > > } > > > > > > > > > > > > +static struct obj_cgroup *get_obj_cgroup_from_memcg(struct mem_cgroup *memcg) > > > > > > +{ > > > > > > + struct obj_cgroup *objcg; > > > > > > + > > > > > > + if (memcg_kmem_bypass()) > > > > > > + return NULL; > > > > > > + > > > > > > + rcu_read_lock(); > > > > > > + objcg = __get_obj_cgroup_from_memcg(memcg); > > > > > > + rcu_read_unlock(); > > > > > > + return objcg; > > > > > > > > > > This code doesn't make sense to me. What does rcu read lock protect here? > > > > > > > > To protect rcu_dereference(memcg->objcg);. > > > > Doesn't it need the read rcu lock ? > > > > > > No, it's not how rcu works. Please, take a look at the docs here: > > > https://docs.kernel.org/RCU/whatisRCU.html#whatisrcu . > > > In particular, it describes this specific case very well. > > > > > > In 2 words, you don't protect the rcu_dereference() call, you protect the pointer > > > > I just copied and pasted rcu_dereference(memcg->objcg) there to make it clear. > > Actually it protects memcg->objcg, doesn't it ? > > > > > you get, cause it's valid only inside the rcu read section. After rcu_read_unlock() > > > it might point at a random data, because the protected object can be already freed. > > > > > > > Are you sure? > > Can't the obj_cgroup_tryget(objcg) prevent it from being freed ? > > Ok, now I see where it comes from. You copy-pasted it from get_obj_cgroup_from_current()? > There rcu read lock section protects memcg, not objcg. Could you pls explain in detail why we should protect memcg instead of objcg ? Why does the memcg need the read rcu lock ? > In your case you don't need it, because memcg is passed as a parameter to the function, > so it's the duty of the caller to ensure the lifetime of memcg. > I'm still a bit confused. See below, objcg = rcu_dereference(memcg->objcg); percpu_ref_tryget(&objcg->refcnt); <<<< what if the objcg is freed before this operation ?? -- Regards Yafang