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 BF0DEC433EF for ; Mon, 15 Nov 2021 18:55:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6807D63661 for ; Mon, 15 Nov 2021 18:55:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6807D63661 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 DB5BF6B007B; Mon, 15 Nov 2021 13:55:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D65646B007D; Mon, 15 Nov 2021 13:55:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C54EA6B007E; Mon, 15 Nov 2021 13:55:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0023.hostedemail.com [216.40.44.23]) by kanga.kvack.org (Postfix) with ESMTP id B83DB6B007B for ; Mon, 15 Nov 2021 13:55:55 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 680BA84CEE for ; Mon, 15 Nov 2021 18:55:55 +0000 (UTC) X-FDA: 78812069070.29.9DAE2FC Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) by imf10.hostedemail.com (Postfix) with ESMTP id 5C98060019B7 for ; Mon, 15 Nov 2021 18:55:37 +0000 (UTC) Received: by mail-il1-f179.google.com with SMTP id h2so17716284ili.11 for ; Mon, 15 Nov 2021 10:55:53 -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=tSucHjGcT6rkKlRqoilO8gpQKCTFkj/1xgEEhZp5eAs=; b=shPjg8V/5u2dqDLkaXzmMZAZMsCcQsR6PFojLDP+XysioiAsZ4MWDBMH6lj/nqs6gK gng1bRyO6QvcnTO5lOmQ6W+fJmAbMq4U84LN21NdUpOJ2TZB5iUf/WOZOMIeN3CqxYkr IHjlp6d6zLWOSnmsbK5LHmMacY5TAnn2yOu9iGU4BUJdGHzhHKyMsjsOc1lEugx33ZlJ MMDWKgTqqpjDhcSTU/d5FYsk3P3mMUlTtDK0R2zHrkggCNZie+YAQPwf4MNanrevjkqc uXoPpauDl8mPczO61WBkh+P/51kTrT4iziFFSqwAX75MuRSaSUNqvyAax4bMnnKdg4vZ xekw== 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=tSucHjGcT6rkKlRqoilO8gpQKCTFkj/1xgEEhZp5eAs=; b=L6sWA1MWQi3lt2U1DCPs0a/9hjc1B6i3UBNE+HatI8bK1lW2Lgvt6z/AO1b3hmNCKC A5hUgtGSnfwKMn+vp/UybcDCGQdbePIpDl4RfvVE01epQ+VAddV6wLC26gPVGkVzFO4C E2wEk/c4+bLW5ULVP+3A3aNqRIxTPBsdZOCoXYGqNCLwZmd9HqnD3M9lpLyYqWGM+2+s P7E/Ls7hLycjzbGMYG/JS23yUsx1TeRZWFCiv2pwKshR9J/sodt9A95PepBH+WU4prCN M8QOvShMIoRd/cb0OBPzQdnVEVBXjWa5GAkekbc/RaIlM8DZUwZAJziH9pLJUK3M38ju fmXw== X-Gm-Message-State: AOAM532S+e7H4TRZymBfkxSzfLluk+fscPUSaCWLo0idYIJaiHMAPUkd FElbM8U6HHDGustJqb33G7YqR9h/sF5gzxwVjIeAfA== X-Google-Smtp-Source: ABdhPJzz/r513GfRNjO6TK5we9g+gjG84Zhlrk5AIOCmQVGEOVogXCQfWGjXf4QWkxK7t8FkTXXsFpZUnaWHoUz7zgY= X-Received: by 2002:a92:c569:: with SMTP id b9mr714347ilj.39.1637002552537; Mon, 15 Nov 2021 10:55:52 -0800 (PST) MIME-Version: 1.0 References: <20211111015037.4092956-1-almasrymina@google.com> <6887a91a-9ec8-e06e-4507-b2dff701a147@oracle.com> In-Reply-To: <6887a91a-9ec8-e06e-4507-b2dff701a147@oracle.com> From: Mina Almasry Date: Mon, 15 Nov 2021 10:55:41 -0800 Message-ID: Subject: Re: [PATCH v6] hugetlb: Add hugetlb.*.numa_stat file To: Mike Kravetz Cc: Muchun Song , Shakeel Butt , 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 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5C98060019B7 X-Stat-Signature: xibaprauz8dp37oohfyqhfzxm9oe3bys Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="shPjg8V/"; spf=pass (imf10.hostedemail.com: domain of almasrymina@google.com designates 209.85.166.179 as permitted sender) smtp.mailfrom=almasrymina@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1637002537-72618 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:22 AM Mike Kravetz wro= te: > > 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 Memory= 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 wrot= e: > > >> 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 and > > >> possible garbage value on archs which do not support atomic writes to > > >> unsigned long. > > > > > > At least I totally agree with you. Thanks for your detailed explanation= . > > > > > > > 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? > -- > > Mike Kravetz >