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=-8.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=unavailable 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 78775C2D0B1 for ; Thu, 6 Feb 2020 14:05:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 29E9D217F4 for ; Thu, 6 Feb 2020 14:05:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lca.pw header.i=@lca.pw header.b="biwqBwiM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29E9D217F4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lca.pw Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C4F826B0003; Thu, 6 Feb 2020 09:05:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BFE316B0006; Thu, 6 Feb 2020 09:05:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B13D06B0007; Thu, 6 Feb 2020 09:05:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 99D856B0003 for ; Thu, 6 Feb 2020 09:05:44 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 392148248047 for ; Thu, 6 Feb 2020 14:05:44 +0000 (UTC) X-FDA: 76459875408.25.night39_63ae462f6091a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin25.hostedemail.com (Postfix) with ESMTP id A64EB1804F19C for ; Thu, 6 Feb 2020 14:01:25 +0000 (UTC) X-HE-Tag: night39_63ae462f6091a X-Filterd-Recvd-Size: 6778 Received: from mail-qv1-f66.google.com (mail-qv1-f66.google.com [209.85.219.66]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Thu, 6 Feb 2020 14:01:24 +0000 (UTC) Received: by mail-qv1-f66.google.com with SMTP id g6so2867836qvy.5 for ; Thu, 06 Feb 2020 06:01:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=L9C8qzeLGecp6MibU+zz8IQnQpkCpPY0Z5NyRniIhZg=; b=biwqBwiM7hHH0dL9cRlaKCx4diR6R8gCGHdwBlsDVTGJqp9Yi2F3fL9gDACQqIhBaj +WUo9m6XaQqPuDmsrsuZzsVo1lxSJm4zdgZuYtACXk3Le6Pal3ILqrJ3fZmf74hf2BLA cmyO4Eec6zatppnKkaFeOmqhXCnM8K0wozXH19IoegYk661TaK2u87ahJyGKdsYx+iWo 4ELNjteN+09ISZ49wF2Q1CSB1VQstJZt+bzLnwPoKrrGhnHGCArdp88VCKSwRBRMPKDx eq4979kHA8C/1hxC1bPSzuD8aq5vNxMH2rVANFuGmPq8XNGP1m2hVN1aQ9nDYIh9eod0 8Gag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=L9C8qzeLGecp6MibU+zz8IQnQpkCpPY0Z5NyRniIhZg=; b=Km8nmnrK/JTXTsESTeBTFnmc5/PjYdGH3Y43ajFZfpVGhG3Qpmo32rWPjz4hLpISj9 q+Shq1u693uge4EwymYWNZJXztDJMlz9QsPP0mpwEduaM40qWsN9DT8wZu1pdCY8yPGb z6CVxlZdeUcn3wzy+hguocvM9x31c69tnzeEU5Ar9kep/BVdpbweQfnmPKLBZtkLDSMT M+QINHk91Wph1wt9yaoIGy9GHYYXfgavZBYiVUtHHA0sYUoADNE/blUcGIz16lbCTP5B JqUpQRa9spLdO4szSETOjxnCRK2yuQqB1oegv+EZFqkGNbyHTBI3o7OxI7aICZ7WHPVk 73jw== X-Gm-Message-State: APjAAAVpN3LOxTzHWcM3j8HI8uF9xKYh36l++ZiJwgcbrqTigvqa7TVS GSt/ByNSLDNlQBJjNKPh+zsR9w== X-Google-Smtp-Source: APXvYqx8L0U9nIMMo9Uz38/l0opNMUQCU9QBV9wOBlyte26vC9Frrj5Tc9qoWlSnmrV3cX6hl8dUrQ== X-Received: by 2002:a05:6214:1150:: with SMTP id b16mr2444019qvt.71.1580997683177; Thu, 06 Feb 2020 06:01:23 -0800 (PST) Received: from dhcp-41-57.bos.redhat.com (nat-pool-bos-t.redhat.com. [66.187.233.206]) by smtp.gmail.com with ESMTPSA id v78sm1485309qkb.48.2020.02.06.06.01.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 06:01:22 -0800 (PST) Message-ID: <1580997681.7365.14.camel@lca.pw> Subject: Re: [PATCH -next] mm: mark a intentional data race in page_zonenum() From: Qian Cai To: John Hubbard , akpm@linux-foundation.org Cc: ira.weiny@intel.com, dan.j.williams@intel.com, jack@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org, elver@google.com Date: Thu, 06 Feb 2020 09:01:21 -0500 In-Reply-To: <480a7dde-f678-c07b-2231-4da8e0a38753@nvidia.com> References: <20200206035235.2537-1-cai@lca.pw> <480a7dde-f678-c07b-2231-4da8e0a38753@nvidia.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-10.el7) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Wed, 2020-02-05 at 20:50 -0800, John Hubbard wrote: > On 2/5/20 7:52 PM, Qian Cai wrote: > > The commit 07d802699528 ("mm: devmap: refactor 1-based refcounting for > > ZONE_DEVICE pages") introduced a data race as page->flags could be > > Hi, > > I really don't think so. This "race" was there long before that commit. > Anyway, more below: > > > accessed concurrently as noticied by KCSAN, > > > > BUG: KCSAN: data-race in page_cpupid_xchg_last / put_page > > > > write (marked) to 0xfffffc0d48ec1a00 of 8 bytes by task 91442 on cpu 3: > > page_cpupid_xchg_last+0x51/0x80 > > page_cpupid_xchg_last at mm/mmzone.c:109 (discriminator 11) > > wp_page_reuse+0x3e/0xc0 > > wp_page_reuse at mm/memory.c:2453 > > do_wp_page+0x472/0x7b0 > > do_wp_page at mm/memory.c:2798 > > __handle_mm_fault+0xcb0/0xd00 > > handle_pte_fault at mm/memory.c:4049 > > (inlined by) __handle_mm_fault at mm/memory.c:4163 > > handle_mm_fault+0xfc/0x2f0 > > handle_mm_fault at mm/memory.c:4200 > > do_page_fault+0x263/0x6f9 > > do_user_addr_fault at arch/x86/mm/fault.c:1465 > > (inlined by) do_page_fault at arch/x86/mm/fault.c:1539 > > page_fault+0x34/0x40 > > > > read to 0xfffffc0d48ec1a00 of 8 bytes by task 94817 on cpu 69: > > put_page+0x15a/0x1f0 > > page_zonenum at include/linux/mm.h:923 > > (inlined by) is_zone_device_page at include/linux/mm.h:929 > > (inlined by) page_is_devmap_managed at include/linux/mm.h:948 > > (inlined by) put_page at include/linux/mm.h:1023 > > wp_page_copy+0x571/0x930 > > wp_page_copy at mm/memory.c:2615 > > do_wp_page+0x107/0x7b0 > > __handle_mm_fault+0xcb0/0xd00 > > handle_mm_fault+0xfc/0x2f0 > > do_page_fault+0x263/0x6f9 > > page_fault+0x34/0x40 > > > > Reported by Kernel Concurrency Sanitizer on: > > CPU: 69 PID: 94817 Comm: systemd-udevd Tainted: G W O L 5.5.0-next-20200204+ #6 > > Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019 > > > > Both the read and write are done only with the non-exclusive mmap_sem > > held. Since the read only check for a specific bit in the flag, even if > > > Perhaps a clearer explanation is that the read of the page flags is always > looking at a bit range (zone number: up to 3 bits) that is not being written to by > the writer. > > > > load tearing happens, it will be harmless, so just mark it as an > > intentional data races using the data_race() macro. > > > > Signed-off-by: Qian Cai > > --- > > include/linux/mm.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > 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.