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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D940DC433F5 for ; Mon, 15 Nov 2021 19:59:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6D4B661B53 for ; Mon, 15 Nov 2021 19:59:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6D4B661B53 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id E56906B0082; Mon, 15 Nov 2021 14:59:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E06C66B0083; Mon, 15 Nov 2021 14:59:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF7406B0085; Mon, 15 Nov 2021 14:59:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0204.hostedemail.com [216.40.44.204]) by kanga.kvack.org (Postfix) with ESMTP id C139B6B0082 for ; Mon, 15 Nov 2021 14:59:18 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 80CA3180AA992 for ; Mon, 15 Nov 2021 19:59:18 +0000 (UTC) X-FDA: 78812228796.28.3E28203 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf18.hostedemail.com (Postfix) with ESMTP id 29B604002092 for ; Mon, 15 Nov 2021 19:59:18 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id bi37so41658671lfb.5 for ; Mon, 15 Nov 2021 11:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bvO6+jUD2mJW1UC7y5qeYQeTnfpZN547VLV7YgyXAGk=; b=qqov+BzX7laf/ZvbnmqQgqWQZGU9HYEeiHbsQhDAVGGlv66PY74t+XuKDjedOLrHRi LpsXRyr9z0S0IesXCOUBZKjBYMmztagwoaBgalfbRrxhoTKwdlfIZLO3/d/w5x/fKANO JCoq7L6l7rBdWlBB1ngUSwUYJU5eRmbhB3DIpOsvNT/IDQJu7xwHUSGJGxcb1QIlW0pS qDGPKd3UXL7hHxF6IAzZi6kXmhsYDYDW9m1uY9E42FkqwCObJ/IgOcE2PhsRAhH2B0AA nwRcea6Y+rAoKmCWgMfnJDIi3QAprLUQTEjMrKM6OTkGVeBLszE7HOhVlfQaDaeIxOFt 7eKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bvO6+jUD2mJW1UC7y5qeYQeTnfpZN547VLV7YgyXAGk=; b=YPwiZzInvFaTF1lmZujj39DS7g8dPW67v5OZKbqzakutIfv2kwlWvblol3RXtcIjhj aZlVrEWlflvkSMuvry99d2PcpnzTxCfeFK4KbY5NE1Bqqf/NpXPyYqROVIkoW+j71uYl R7PiZv+LkZzkqXADVmjxOLu+ac8ck3/tWygDhbf5l+gFBpwFtJ0/YiwJJXPjaPk9eh/r phizJSD3V2n5Jt0YQuIhkFgKpeEigWLeg1ycsdybCY+YcI/Dt35Rxj0UnIAZfUBIELDX /Bg89hwLp5FHs0wMt3l9S9hUMJe3mDLJUKtHxHoRboOgDxEgZf9xw57fnj2+Rnw0o7z6 jBUA== X-Gm-Message-State: AOAM530TnZNiuHKBiZ794NwSgRn8HO2liBuT8qMg3EkxJmQScNOthP09 hMiW2hGwdHfSxsoewkFo4TlBvoYblr2bArDUQ3taOw== X-Google-Smtp-Source: ABdhPJwPT2yBfWQWiQx2895cp83Iu148A7FQbjPlqJjVMESBp8jP2FgR3QkSFB3K+S80lU80ZBXwECWAoSZumjikBvQ= X-Received: by 2002:a05:6512:1113:: with SMTP id l19mr1243783lfg.184.1637006356326; Mon, 15 Nov 2021 11:59:16 -0800 (PST) MIME-Version: 1.0 References: <20211111015037.4092956-1-almasrymina@google.com> <6887a91a-9ec8-e06e-4507-b2dff701a147@oracle.com> In-Reply-To: From: Shakeel Butt Date: Mon, 15 Nov 2021 11:59:03 -0800 Message-ID: Subject: Re: [PATCH v6] hugetlb: Add hugetlb.*.numa_stat file To: Mina Almasry , Marco Elver , paulmck@kernel.org Cc: Mike Kravetz , Muchun Song , Andrew Morton , Shuah Khan , Miaohe Lin , Oscar Salvador , Michal Hocko , David Rientjes , Jue Wang , Yang Yao , Joanna Li , Cannon Matthews , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=qqov+BzX; spf=pass (imf18.hostedemail.com: domain of shakeelb@google.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 29B604002092 X-Stat-Signature: gecabjij5jurrpbqrsyuw1u1zrtj9hia X-HE-Tag: 1637006358-682188 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 Mon, Nov 15, 2021 at 10:55 AM Mina Almasry wrot= e: > > On Mon, Nov 15, 2021 at 10:22 AM Mike Kravetz w= rote: > > > > Subject: Re: [PATCH v6] hugetlb: Add hugetlb.*.numa_stat file > > > > To: Muchun Song , Shakeel Butt , Mina Almasry > > > > Cc: Andrew Morton , Shuah Khan , Miaohe Lin , Oscar Salvador , Michal Hocko , David Rientjes , Jue Wang , Yang Yao , Joanna Li , Cannon Matthews , Linux Memo= ry Management List , LKML > > > > Bcc: > > > > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D# Don't remove this line #=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D- > > > > On 11/14/21 5:43 AM, Muchun Song wrote: > > > > > On Sun, Nov 14, 2021 at 3:15 AM Shakeel Butt wr= ote: > > > > >> On Sat, Nov 13, 2021 at 6:48 AM Mina Almasry wrote: > > > > >>> On Fri, Nov 12, 2021 at 6:45 PM Muchun Song wrote: > > > > >>>> On Sat, Nov 13, 2021 at 7:36 AM Mike Kravetz wrote: > > > > >> We have following options: > > > > >> > > > > >> 1) Use atomic type for usage. > > > > >> 2) Use "unsigned long" for usage along with WRITE_ONCE/READ_ONCE. > > > > >> 3) Use hugetlb_lock for hugetlb_cgroup_read_numa_stat as well. > > > > >> > > > > >> All options are valid but we would like to avoid (3). > > > > >> > > > > >> What if we use "unsigned long" type but without READ_ONCE/WRITE_ONCE= . > > > > >> The potential issues with that are KCSAN will report this as race an= d > > > > >> possible garbage value on archs which do not support atomic writes t= o > > > > >> unsigned long. > > > > > > > > > > At least I totally agree with you. Thanks for your detailed explanati= on. > > > > > > > > > > > > > Thanks everyone. This makes sense. > > > > > > > > However, I should note that this same situation (updates to unsigned > > > > long variables under lock and reads of the the same variable without > > > > lock or READ/WRITE_ONCE) exists in hugetlb sysfs files today. Not > > > > suggesting that this makes it OK to ignore the potential issue. Just > > > > wanted to point this out. > > > > Sorry I'm still a bit confused. READ_ONCE/WRITE_ONCE isn't documented > to provide atomicity to the write or read, just prevents the compiler > from re-ordering them. Is there something I'm missing, or is the > suggestion to add READ_ONCE/WRITE_ONCE simply to supress the KCSAN > warnings? > +Paul & Marco Let's ask the experts. We have a "unsigned long usage" variable that is updated within a lock (hugetlb_lock) but is read without the lock. Q1) I think KCSAN will complain about it and READ_ONCE() in the unlocked read path should be good enough to silent KCSAN. So, the question is should we still use WRITE_ONCE() as well for usage within hugetlb_lock? Q2) Second question is more about 64 bit archs breaking a 64 bit write into two 32 bit writes. Is this a real issue? If yes, then the combination of READ_ONCE()/WRITE_ONCE() are good enough for the given use-case? thanks, Shakeel