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 1920CC61DA3 for ; Tue, 21 Feb 2023 18:15:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E8196B0073; Tue, 21 Feb 2023 13:15:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 798A56B0074; Tue, 21 Feb 2023 13:15:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 660686B0078; Tue, 21 Feb 2023 13:15:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 56C776B0073 for ; Tue, 21 Feb 2023 13:15:40 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 106E0A07DA for ; Tue, 21 Feb 2023 18:15:40 +0000 (UTC) X-FDA: 80492102040.12.9F6F495 Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf09.hostedemail.com (Postfix) with ESMTP id 383F3140028 for ; Tue, 21 Feb 2023 18:15:37 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=YGdztCTl; spf=pass (imf09.hostedemail.com: domain of shakeelb@google.com designates 209.85.219.182 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=1677003337; 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=pOgO/w06KVBEyUXIMY7wyQCGQx5gFUoRCVeioCjbV5M=; b=rvNeN0smy5KQULkhJENVB8hUyNHlLYeXGg2IhcR764aQX2Ch2OobS1xd7aLV/6Q0xaxK19 uX6RgNatEMFVXUJhOeiw5HPcriXYNHTN2zy5M9LiswEQx9sdSehdaZing9ikzAU++dSy7p nr/j7JGyyKK/dTlteAXxR0i05nI0bR8= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=YGdztCTl; spf=pass (imf09.hostedemail.com: domain of shakeelb@google.com designates 209.85.219.182 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=1677003337; a=rsa-sha256; cv=none; b=2V/YJFR7ExihTeBwiNF46eVo3ToGSq2ZJB4715Xy0zm0yNNRazAj7VFYPlb6VetuKAthg3 4F3JxZWnwrTvERIgmoz+INXA8+r1TRr46/68IStOwjl8Puysgrv1O7p7GEz0rZ6gw8TXGw 8e27Cyv4NPN92d6u5pwS7HFVfEvdCL0= Received: by mail-yb1-f182.google.com with SMTP id e82so7253153ybh.9 for ; Tue, 21 Feb 2023 10:15:36 -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=pOgO/w06KVBEyUXIMY7wyQCGQx5gFUoRCVeioCjbV5M=; b=YGdztCTlaHrRbsKTCaOZcHg4zoVQf9sO6DhN0S+s8gLe9egkas2r1pR7vjCXOgIDck NJWuc3v0C6KuSOJmV2M0Eg8v2xOsHEgfWvu8vifqTwy0xOPsd33J5Lss/yNGsDerodKO Zh8QCfkTre3S5aJ58OkBgvlwhc9zeduIYtTYNB6un1RFp/q5lf/26EkHnKZ2HBzPVttS MMC13lP+IWG1Xi7/wGG7sA95MqHpkkZRUq3zHeGYfSGnijOLMz+IoUN1/nwRAayGCORs iJTF04oB/MCC31ZJoQseePfV43knWNWbVLcgUsyfFIAqowZPp/hixJziw4kKmA52WjFn LPwA== 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=pOgO/w06KVBEyUXIMY7wyQCGQx5gFUoRCVeioCjbV5M=; b=2DEBHFSCM1ftvef9vzRkcoY86n5hnrcBIRVhP/vRxJNERl+3u7968dzqxC621tgMf4 a1QVggZ9aTkLKGhzD97D+WDudCfsadwD9K3OzSxYonX3dr0Usy0WZEklf4HhvvstIs4t Gw+9xuhP/XqzNNTGaZuvSYCv4cxsz3J+mAPaWOcHADqOR4IKRgbuHsKP2tUngGeQc8JD fKgwsYFwFGSkCcJzCJm5LUgPOZ1tK9IEt2Z6DMxWm8B55268weHHPF+Q9hq1x2Z9qUx3 F4pMId46MeYYD9hON/NZ4CjdPcRBbwbCSjPduALvbhL+h+2cgKAa7qXUUhxnwPT8vWdf dD0w== X-Gm-Message-State: AO0yUKU2AKCMboYKa6dmzBNppempKWXauZh82p8RJJXxcZbOUQWs1+uf SvpWKRwHPExlS4qbW6cGLFoPLXMSr9WpZteGjMaGnw== X-Google-Smtp-Source: AK7set9LH96P4CUu3oy9ckxPmJKWvYmcMNfbFLClOPwWL6qNKvmP55A/US6aPp8rCqa3Yk0nA4nUomosALyKjNV9efU= X-Received: by 2002:a5b:cc:0:b0:966:a047:4ce4 with SMTP id d12-20020a5b00cc000000b00966a0474ce4mr555033ybp.10.1677003335981; Tue, 21 Feb 2023 10:15:35 -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 10:15:24 -0800 Message-ID: Subject: Re: [PATCH] mm: change memcg->oom_group access with atomic operations To: Roman Gushchin Cc: Matthew Wilcox , 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-Stat-Signature: wyw8copcgqk7cischxgjc1ga7cnup69i X-Rspam-User: X-Rspamd-Queue-Id: 383F3140028 X-Rspamd-Server: rspam06 X-HE-Tag: 1677003337-32966 X-HE-Meta: U2FsdGVkX1+wufUSRMC3AY5hLYOAq4AdACmHFdfCsAmq1h7Y6KUiNDwXew5EBtM0J1AmxkDCawiQUHAWeDqRMz2fWfP2U/WErqUuk0EGvTLW0lOp8IFlHodks3I9gcs7VXIsuWPtlkl3NcsSPqra+ZIWXJvtXtDnArfaiajpHnYMMCErppo3reVLTFAx9dkah0vBPPe6AOe+D8YE8aX3KO6uemwsAUzQUiQ8GRRgwm1lNvtfI7kh84HjSJ5ZvGU4tFAV7y1OAmWJRdaK1dyzIyFhtOiXOhNVQq3Bu6sxwEUxwnOiP5lBFG5zbbegL0m/27vMVN6fvYC5bCQDXILVQWluDceKt99mFsIYzV24dkaPQRnpJij9QaBRbXNUsMR0GFQQ15d6i+ZchaPpxPCJQCeJU7qC+WQtsWw4rEseqr21gtw/QXBHMeXnc/9QRNXouZ9vZiButuhNwDl4ZI+9vn/nO+YdS8AIhlS94hM/vUlYoD0ia1mzoF6JXour+Tbb2XC+HWQ3CYfwlgz1J/H9Whuq+ukMXLX8Q8xOy5vn+zDouNrunaNYYyn+qOe8r6pqJtKAdRSLZxr5wAxHqxgZK4LxRQVQsNxZWHqYjZytaTmf0vrbJhR2bFLcPZYoe7sAJo49ieIAaEBol6ikKVUQzEYsMn5+P9qU9EIxuL6HDZorBatEd/p+50ZTXPs9a+7j9XAW8L5O4f/fQT1AAhCQOjm9anh4MDNEEv3stK2mlMrGEnX8ZiH1ZCcU6YQ55GnGILkjl6ndlfDAr3nSQvenjM2HBVlfouz5do9V8D3DJEamBNmx/3OEpn+VZt1kYebstR6s4xjivFOgALKb6vmKEU352Z71h3EJHLV+gmaKr9p79WtLe8gYqLfO73wXrPbzT4BsJSnxfdNhSzQ7zDE2Ez7meZ5cn9mVDfYLYcILtPRq/ODnk7Mc0xaWmxsGRgnRkUafZIxN/odwRyTas4i pv4bFKUC Lx5XQgIClouogCZw+wOHZp3wf0sgWU+WN7gE+oHwc+98nTtgJdElJoBbjjS657KDf7fiOA/VWCOFwLaeaVbJqaQ+plrdRg9sV+7dVwZXVMoAV5JeQuNuMTFUMdM6UnoE6yK71HDFYJsxmXG7R4M/Yh0A6D2f9lH0vwAJlc4sv/orTlSY2oyBtowtFqXJNqMJf06hayIqdPWTZE4M2Lhr1NC0hARmojRkldSt4D4sS+i120U/s8y+dhs2WckWk4KYb5MlLYwSnMFDBAMEYSOMEO28VO6uFLP8lZk4Ol4SZftTh639WR9qqdpybcbH9Wf7IkPb2hlIzrlgvwEv347wxslXQDA== 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 Tue, Feb 21, 2023 at 9:47 AM Roman Gushchin w= rote: > > On Tue, Feb 21, 2023 at 01:51:29PM +0000, 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 w= rote: > > > > > > > > > > =EF=BB=BFOn Mon, Feb 20, 2023 at 01:09:44PM -0800, Roman Gushchin= wrote: > > > > >>> 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 s= olving? > > > > >> 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/writ= e > > > 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 al= so > > 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. > > Even then it's not an issue in this case, as we end up with either 0 or 1= , > I don't see how we can screw things up here. > What do you mean by this is not an issue in this case? Yes, the oom_group usage will be ok but we can not say anything about the adjacent byte/fields.