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 605B7C61DA3 for ; Tue, 21 Feb 2023 16:57:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DCF8D6B0073; Tue, 21 Feb 2023 11:57:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D59596B0074; Tue, 21 Feb 2023 11:57:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C204B6B0078; Tue, 21 Feb 2023 11:57:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id AC8186B0073 for ; Tue, 21 Feb 2023 11:57:14 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 865ED14074F for ; Tue, 21 Feb 2023 16:57:14 +0000 (UTC) X-FDA: 80491904388.01.548385A Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf19.hostedemail.com (Postfix) with ESMTP id 4C20E1A0013 for ; Tue, 21 Feb 2023 16:57:11 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=T+TvPcrc; spf=pass (imf19.hostedemail.com: domain of shakeelb@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676998631; 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=TfWrKhC0Efcbpjp7w2MXsBIaeBw0Ifz30UZjyvdXZU8=; b=d0TxAJocOi2xJ96fT0WO52J3f4C7lH1vAMovaPwq3bsXsSqEAI9zSgTCN5ptD/Ylg7JbpX iuViOe1z/hRDTzB9a14CJj0REC7DRcrIEC8FzYWhjK/L4gkEslaMsFu1aGfStYK+mCipd/ Zx0t+6a1QI05dpk+efw6N0zVD5dMIi8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=T+TvPcrc; spf=pass (imf19.hostedemail.com: domain of shakeelb@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676998631; a=rsa-sha256; cv=none; b=aXzFn8AVPXisjc56Q4hSF/fVnOqDqceFnwN/yEsvUWYty/UBdakXyjtt/A80juTao5WX3F g+5C6CVBR+EYwXxJEVioHi8INw66k1i3f0dDxWxuqV+ESWo3tg/UY1ck8LxM75XIns39T6 LFS9zpOFU+bwzvLBb+jsZDLz/4QMyro= Received: by mail-yb1-f173.google.com with SMTP id cf8so5213895ybb.11 for ; Tue, 21 Feb 2023 08:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=TfWrKhC0Efcbpjp7w2MXsBIaeBw0Ifz30UZjyvdXZU8=; b=T+TvPcrcFUKrIua4z6RQ1S+jaZ0P9bUBa/CVTFhVVu5KyCr2lY+itYJuXh8njQZOyO TUsUmevowwVhXmxwvkBfVYi4nDHO1oA2g+YerK6gzZS5pU2VFYt8ub8vt9ZyYGFjnrH2 BOrqE4LH8nzrr2/mPQjW5Pi3d+T+crSDuEBRGZUqTN4t/YDHoOFMc4hU5knIy8DCk5sG TK/8HYz2FnR8oiJTGrdxBzlfnXICjNhWuJ+hau8wiabqlvl5Vl5+YhyfvV1gwnO33QCd R1ndg/MrlKjhTox2ibB+MD0EEzL2tNw4kRxtG7WhMsfdIW/GaPcCH/P/HmSKpv1fwzPM +lCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=TfWrKhC0Efcbpjp7w2MXsBIaeBw0Ifz30UZjyvdXZU8=; b=uARVJKxrx6oDTDX1NDAnfqPOWOIQMeRDaafIL5S6+JCJilzrKFAzd7zcLeXqXAsNqe zUR4mmSLQ+jLpJ2KnOl/OUZrdaCSnyF6G/OU7ZB9kCTYnAiHisHvIooipM/NIjZip9NB sTgM2DWr1nHEZBuxZQQcIaJYz00q6TKqQEr13l0Py/cINlbeb5qetjgS2MaLW68PAhCF EXUjeUoZ1sWpwB+Ek45iuBAeSwSCFyuOmoBMaFouFBZ52gE48YiAAqu7eqCfhOMlZNzD 1pobmUmi4dtRdv7RBYIWlzDswes9msJzyHQ44WrqaiJbsu27nWKOwVsyqiz7TmkWVJno dQEA== X-Gm-Message-State: AO0yUKU/KUUm1U8iCEYi4aHP5b8NpInMBw2a07Uf8mmEtcuo/gIhOxQt k3Xk7mD9FyFCEJbvcLED9bSKhW6p5ij05JXqIjETBw== X-Google-Smtp-Source: AK7set9A8u6VEqmytgi8+HBZJmlK4fLnoUHs+bnR0vNjMgaTc5H7RcLClklBqNhakQilr9QwcNWjLCWtW/zyQdkNp/Y= X-Received: by 2002:a5b:691:0:b0:902:535c:8399 with SMTP id j17-20020a5b0691000000b00902535c8399mr191198ybq.461.1676998630231; Tue, 21 Feb 2023 08:57:10 -0800 (PST) MIME-Version: 1.0 References: <20230220230624.lkobqeagycx7bi7p@google.com> <6563189C-7765-4FFA-A8F2-A5CC4860A1EF@linux.dev> In-Reply-To: From: Shakeel Butt Date: Tue, 21 Feb 2023 08:56:59 -0800 Message-ID: Subject: Re: [PATCH] mm: change memcg->oom_group access with atomic operations To: Matthew Wilcox , "Paul E. McKenney" , Marco Elver Cc: Roman Gushchin , Yue Zhao , linux-mm@kvack.org, akpm@linux-foundation.org, hannes@cmpxchg.org, mhocko@kernel.org, muchun.song@linux.dev, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4C20E1A0013 X-Stat-Signature: kektz3dsn8q4nn97ujgta1ckragnb35g X-Rspam-User: X-HE-Tag: 1676998631-736535 X-HE-Meta: U2FsdGVkX18ERJNNwJDmkrC3Ds0rQyClr57qfhCO5i7IOIRXR2seveWRO2ZDRGRgggtc/mXQRmX4tH+wC7H35Ryn4MHieGBtR8shSl61JPjfPPPg+1o/kF+6kufRmLLynsEkPBqBJ6dMuD750N2dtUvzRaCQERUGP2pskqL/hRyu4scWA2S2CjrgH6RZky3uz6OA22O10Qiz3cqe5tgmbUyfx1Ff9rP/+ZxEGKaGgtRc0YuK3UC87myawHETWSq3PO3zUW8xMoov/M8mznOxQD5usWoqal89Nl67VaswjjVcEQ/cxhMFuDx0MngDpiHPFyZrd6HAjyZuWH6j9HIzU8qiAqBR34wZRH+O41y766RoJQnyIFdHm3JSQByFYJrSMIv1zCpAQ+FovHLgXBf65i7ikcJPiUF314TylxwvgqjN0REf63+i/34xgX2OVXRJpFyr6XaOF3mttglxv+QPa2YTrISJBGDpvy+97kGoe5rztkHfmjswb6ulwmVpVW9GGKn5l+drxH9FCXACS13GhQFzZdzvsl1xXTuuU9seqF7b2QynARl0T7Fkqus1/GUAfOPrdVZRCIME98mzs3uEE5d+P/vc7c1lJeBn7Q7kZnfx6QX9gvybDa4JsTLnYb8ouEnBFdBRhazdUL6AN5xSDWDumXY3X4P3FAw1TQLmEkhu3jbqj3WecGSMvoimW4lu35wY/h3r0ZVOZbFKW6PkY0QIaHTQ3RzHbwum0sR3+U2NXM4PDgz5yHFx0R8QnHjdND/FMmazdkRRy7d51NDt4aJhrPdLiIrDX83SAk5HWwQSJqwixl9tVxUQ55QXJ2MI4zN5n98+q41TzuNTTLsGDe1IbdMfdHw5JK3sEw5TYNtFnqB5o20pEz7dyJVIlD0G0woOLy1kUknX+l7uVkqw7WBBk1oyzspfEYKRPEJwutOrt4VUYqsxCNWeQhATot5E2AFPjjPxlaMG2qL8mtU WT8gujoL fyW2v3kbLLVO2yE4HgMHQBBBtkEraDaRHK6hhnGxVM7GYdtT/S1e7nXzDg8pU98qzCSaOPbbJ7KCWmk6rRzZS/DNxmor5oA0VDwnWTZEXKaW/6vTuuOfS8kXOSYSa1Zfk6UeUFr7agTaqI4T4gl9hfPS8Mu2IBOsP62QcEAlyZaMj3Q7I7e3oajCpOxesmMG7m7EAfcvqnGhiqhqbd+iGtcd932qUnYmxyGxKg7kVrsQMLcOH24XbEl5JOpCIgJNVQhmDvJyzCNT3fhqtB1qwVx7Uq+J4sFVFIBxXGWesyDFSWlZqHfLjqLDteeDX1U2WhXfzgu1sFTittKd81MpCo2WLDGhBxuma7mA/VKm4LVzWrA3NwgFKiLDy1H3j9xslaNb90Fk3LAvLedttPzitaqcY+w== 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: +Paul & Marco On Tue, Feb 21, 2023 at 5:51 AM Matthew Wilcox wrote: > > On Mon, Feb 20, 2023 at 10:52:10PM -0800, Shakeel Butt wrote: > > On Mon, Feb 20, 2023 at 9:17 PM Roman Gushchin wrote: > > > > On Feb 20, 2023, at 3:06 PM, Shakeel Butt wro= te: > > > > > > > > =EF=BB=BFOn Mon, Feb 20, 2023 at 01:09:44PM -0800, Roman Gushchin w= rote: > > > >>> On Mon, Feb 20, 2023 at 11:16:38PM +0800, Yue Zhao wrote: > > > >>> The knob for cgroup v2 memory controller: memory.oom.group > > > >>> will be read and written simultaneously by user space > > > >>> programs, thus we'd better change memcg->oom_group access > > > >>> with atomic operations to avoid concurrency problems. > > > >>> > > > >>> Signed-off-by: Yue Zhao > > > >> > > > >> Hi Yue! > > > >> > > > >> I'm curious, have any seen any real issues which your patch is sol= ving? > > > >> Can you, please, provide a bit more details. > > > >> > > > > > > > > IMHO such details are not needed. oom_group is being accessed > > > > concurrently and one of them can be a write access. At least > > > > READ_ONCE/WRITE_ONCE is needed here. > > > > > > Needed for what? > > > > For this particular case, documenting such an access. Though I don't > > think there are any architectures which may tear a one byte read/write > > and merging/refetching is not an issue for this. > > Wouldn't a compiler be within its rights to implement a one byte store as= : > > load-word > modify-byte-in-word > store-word > > and if this is a lockless store to a word which has an adjacent byte also > being modified by another CPU, one of those CPUs can lose its store? > And WRITE_ONCE would prevent the compiler from implementing the store > in that way. > Thanks Willy for pointing this out. If the compiler can really do this then [READ|WRITE]_ONCE are required here. I always have big bad compiler lwn article open in a tab. I couldn't map this transformation to ones mentioned in that article. Do we have name of this one? thanks, Shakeel