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 X-Spam-Level: X-Spam-Status: No, score=-11.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A268C352A4 for ; Fri, 7 Feb 2020 13:18:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3FFE021741 for ; Fri, 7 Feb 2020 13:18:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Bv7+O0Gj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3FFE021741 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CF3836B000A; Fri, 7 Feb 2020 08:18:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CCBA76B000C; Fri, 7 Feb 2020 08:18:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C098D6B000D; Fri, 7 Feb 2020 08:18:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0008.hostedemail.com [216.40.44.8]) by kanga.kvack.org (Postfix) with ESMTP id A5EA16B000A for ; Fri, 7 Feb 2020 08:18:19 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 456E8181AC9CC for ; Fri, 7 Feb 2020 13:18:19 +0000 (UTC) X-FDA: 76463384718.24.fowl60_4899f33964f52 X-HE-Tag: fowl60_4899f33964f52 X-Filterd-Recvd-Size: 5386 Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Fri, 7 Feb 2020 13:18:18 +0000 (UTC) Received: by mail-ot1-f65.google.com with SMTP id j20so2116907otq.3 for ; Fri, 07 Feb 2020 05:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AppHa1mPfAaiV/SFjOWJnS9mSSWNJs8o2NmtKzYnLIM=; b=Bv7+O0Gj9xzAxmxTKrE64kVHWDzLjK/48wyrFk5pv+zPmbR8MwZx8Mq9HSymH0TL+F gBqs2In+xlRc+Bc4Y3A2710Y+mDoCmsm5Phl1ZyDdMonr92CewoH05FNxI7b4vSIuyxp 01lpriTCHmxoLgRRDZdAmRB+ZZ8RtnEgjuAQNztgMRWCX+hr/TL8mYBbbU5FXaN+TYJi KpzEQnEJ/41S/hjd77bv20LD4OrgAjU8T22ThyKEIhiFLJ57CKdXyqWOkUyzlhxaqZpY TSsDfTZeYUgJwDsJJDso9uDZ2kKP4XcI+ZUVnBB9mu0z6TAaTBIr+a3oOsrAlpGO/A6m HokA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AppHa1mPfAaiV/SFjOWJnS9mSSWNJs8o2NmtKzYnLIM=; b=aSDAjRKMKFub8LEhjTZRj+7sQDHtUiVtjPMPcdDVP1lRJnKUeXKlnj0F51ysRW9oba mkZjStL5lKZDtjIK4x3mP/DpLdNtWTiMas+Q4zZrpeXK6hzfehA8uAzSS04Y/1738SqN f88zI7WL0guki2N3AIhCVQ2n7IxRyMLXPHYGb459cMy9S/DgtyO8KGsvtY8KVk0jT0mj 6oM2l+DR2dgjQz+UkuvOZ6iVqx/FnS6WVQGC6oq1FKsxAro2cg8JT2a5So+NPGML52BJ AxkcLLJ9X/BC2nT+dhRDVANjBS2H+FxN+pZZiXaM0A382hLgKnIPzTDyWBsVCxVBT2uT M7wQ== X-Gm-Message-State: APjAAAVh/e2m38OgapdMqfqgnkHDVdWLnSkD7/jKHt/OzU1Cyy4cM7sq 1nwsj70JKcctCfKcdHdjelDepRzgaHFiGDCVuRWGfw== X-Google-Smtp-Source: APXvYqySp8t5lUY8/teOm/qXtbaVzYWnWcBeaLn8p5ibiMGK8WkrVN2kSGBYXg7A0wmRwctJqD8szGVi8N+/sIqUy5g= X-Received: by 2002:a9d:7410:: with SMTP id n16mr2746790otk.23.1581081497948; Fri, 07 Feb 2020 05:18:17 -0800 (PST) MIME-Version: 1.0 References: <20200206035235.2537-1-cai@lca.pw> <480a7dde-f678-c07b-2231-4da8e0a38753@nvidia.com> <1580997681.7365.14.camel@lca.pw> <423eb3c6-6db2-87d2-e0b7-a32600ee1cd4@nvidia.com> In-Reply-To: <423eb3c6-6db2-87d2-e0b7-a32600ee1cd4@nvidia.com> From: Marco Elver Date: Fri, 7 Feb 2020 14:18:06 +0100 Message-ID: Subject: Re: [PATCH -next] mm: mark a intentional data race in page_zonenum() To: John Hubbard Cc: Qian Cai , Andrew Morton , ira.weiny@intel.com, dan.j.williams@intel.com, jack@suse.cz, Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" 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 Fri, 7 Feb 2020 at 00:18, John Hubbard wrote: > > On 2/6/20 6:35 AM, Marco Elver wrote: > ... > >>>> diff --git a/include/linux/mm.h b/include/linux/mm.h > >>>> index 52269e56c514..cafccad584c2 100644 > >>>> --- a/include/linux/mm.h > >>>> +++ b/include/linux/mm.h > >>>> @@ -920,7 +920,7 @@ vm_fault_t finish_mkwrite_fault(struct vm_fault *vmf); > >>>> > >>>> static inline enum zone_type page_zonenum(const struct page *page) > >>>> { > >>>> - return (page->flags >> ZONES_PGSHIFT) & ZONES_MASK; > >>>> + return data_race((page->flags >> ZONES_PGSHIFT) & ZONES_MASK); > >>> > >>> > >>> I don't know about this. Lots of the kernel is written to do this sort > >>> of thing, and adding a load of "data_race()" everywhere is...well, I'm not > >>> sure if it's really the best way. I wonder: could we maybe teach this > >>> kcsan thing to understand a few of the key idioms, particularly about page > >>> flags, instead of annotating all over the place? > >> > >> My understanding is that it is rather difficult to change the compilers, but it > >> is a good question and I Cc Marco who is the maintainer for KCSAN that might > >> give you a definite answer. > > > > The problem is that there is no general idiom where we could say with > > confidence that a data race is safe across the whole kernel. Here it > > Yes. I'm grasping at straws now, but...what about the idiom that page_zonenum() > uses: a set of bits that are "always" (after a certain early point) read-only? > What are your thoughts on that? I have replied to the other thread. Thanks, -- Marco > > might not matter, but somewhere else it might matter a lot. > > > > If you think that it turns out the entire file may be littered with > > 'data_race()', and you do not want to use annotations, you can > > blacklist the file. I already had to do this for other files in mm/, > > because concurrent flag modification/checking is pervasive and a lot > > of them seem 'benign'. We decided to revisit those files later. > > > > Feel free to add 'KCSAN_SANITIZE_memory.o := n' or whatever other > > files you think are full of these to mm/Makefile. > > > > The only problem I see with that is that it's not obvious what is > > concurrently modified and what isn't. The annotations would have > > helped document what is happening. > > > > Thanks, > > -- Marco > > > > > thanks, > -- > John Hubbard > NVIDIA