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=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 96BF6C54EEB for ; Mon, 23 Mar 2020 18:21:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3E4A12072D for ; Mon, 23 Mar 2020 18:21:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="E35zVOra" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E4A12072D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D44D06B0007; Mon, 23 Mar 2020 14:21:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CCCA76B0008; Mon, 23 Mar 2020 14:21:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B46116B000A; Mon, 23 Mar 2020 14:21:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0076.hostedemail.com [216.40.44.76]) by kanga.kvack.org (Postfix) with ESMTP id 8370B6B0007 for ; Mon, 23 Mar 2020 14:21:20 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 32F8AB9F4 for ; Mon, 23 Mar 2020 18:21:20 +0000 (UTC) X-FDA: 76627444320.27.quiet50_78996e20a682c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 390B449F4E for ; Mon, 23 Mar 2020 18:07:09 +0000 (UTC) X-HE-Tag: quiet50_78996e20a682c X-Filterd-Recvd-Size: 6306 Received: from mail-qv1-f67.google.com (mail-qv1-f67.google.com [209.85.219.67]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Mon, 23 Mar 2020 18:07:08 +0000 (UTC) Received: by mail-qv1-f67.google.com with SMTP id o18so7703878qvf.1 for ; Mon, 23 Mar 2020 11:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Ve+05QZoYPi0YuCClTc3ohV/03rfuQ4cI5EZopsltg8=; b=E35zVOramVTjTIS6drDV83CSHrAgJPiYFUoVqNBHtPyK9X35M60UZwZG6SSSLLDYKr q/RqNqf6mOSsd+zI56V1XOoxQZbXKVhpHBYHt5MZHQUFkGhzyG1hNHYzEhnAot+WSWfO kfFNOMiVnVUVs5USpcWkGRWwMiWJi64X9THbLAV55FJRRzpwhfCl7HJZNPWOqra5Sv8h 4NV/Qyj1sQxJHR4LySQ3DXTfik7aePNd5x21MPt/McAvqKJ3a+leXieu9VRHrESgh8jS tRVfxpBZTL43WBIXoijBiFGORijdgIhNfgBX5fRq99kzb7x00bFvRBs0si5toj6xo8+o NxBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Ve+05QZoYPi0YuCClTc3ohV/03rfuQ4cI5EZopsltg8=; b=dIHofx4lEY+eVfftddMH86+yEvNS17ArYhgZpbiK+fUXBmnHDt3g42haTfa5DKf9ON DFJclbUl9DQhrEZ7kFoeiIRG+xO9gi1osJfMb7HdPUybAp/uuBoVXs7hsuKCP+oSn9Kx Keov7GoxC8kaatVjS6eDoHp5QklFTWvGLk/2rJSO7FlHW96PqwCvb9l66ItRnsp+d1pg HrHzZaYbeyEqoJMRHOm5xsNYvPt+pO6i/uB+HaFPdY4lelJ84XecxJyNz+feHwMH7GOj hkTyL8d8wpOyFBMHv7p1FXF29OxfnLUVCUWoYPQAh4HgEfCwJ+BqiVL289Pf44wHEGEP O1vw== X-Gm-Message-State: ANhLgQ3J9Me7B0JYIkpYHABs+sS7ETzTyM5RzeFMDU5x1PWTywUtQpBd E0G6ldGrp9Mc1uLi1UxI49CeHw== X-Google-Smtp-Source: ADFU+vuowy4C5rdMepqxAT9zd7FYcK5Ujxe+LT8j7Las+WeIQGlDbrUdlqbheocEhFlIdJyQaD+iDQ== X-Received: by 2002:ad4:5401:: with SMTP id f1mr1081151qvt.209.1584986827928; Mon, 23 Mar 2020 11:07:07 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-68-57-212.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.57.212]) by smtp.gmail.com with ESMTPSA id c27sm1504978qkk.0.2020.03.23.11.07.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Mar 2020 11:07:07 -0700 (PDT) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1jGRTe-0007Xi-GP; Mon, 23 Mar 2020 15:07:06 -0300 Date: Mon, 23 Mar 2020 15:07:06 -0300 From: Jason Gunthorpe To: Mike Kravetz Cc: "Longpeng (Mike)" , akpm@linux-foundation.org, kirill.shutemov@linux.intel.com, linux-kernel@vger.kernel.org, arei.gonglei@huawei.com, weidong.huang@huawei.com, weifuqiang@huawei.com, kvm@vger.kernel.org, linux-mm@kvack.org, Matthew Wilcox , Sean Christopherson , stable@vger.kernel.org Subject: Re: [PATCH v2] mm/hugetlb: fix a addressing exception caused by huge_pte_offset() Message-ID: <20200323180706.GC20941@ziepe.ca> References: <1582342427-230392-1-git-send-email-longpeng2@huawei.com> <51a25d55-de49-4c0a-c994-bf1a8cfc8638@oracle.com> <20200323160955.GY20941@ziepe.ca> <69055395-e7e5-a8e2-7f3e-f61607149318@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69055395-e7e5-a8e2-7f3e-f61607149318@oracle.com> User-Agent: Mutt/1.9.4 (2018-02-28) 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, Mar 23, 2020 at 10:27:48AM -0700, Mike Kravetz wrote: > > pgd = pgd_offset(mm, addr); > > - if (!pgd_present(*pgd)) > > + if (!pgd_present(READ_ONCE(*pgd))) > > return NULL; > > p4d = p4d_offset(pgd, addr); > > - if (!p4d_present(*p4d)) > > + if (!p4d_present(READ_ONCE(*p4d))) > > return NULL; > > > > pud = pud_offset(p4d, addr); > > One would argue that pgd and p4d can not change from present to !present > during the execution of this code. To me, that seems like the issue which > would cause an issue. Of course, I could be missing something. This I am not sure of, I think it must be true under the read side of the mmap_sem, but probably not guarenteed under RCU.. In any case, it doesn't matter, the fact that *p4d can change at all is problematic. Unwinding the above inlines we get: p4d = p4d_offset(pgd, addr) if (!p4d_present(*p4d)) return NULL; pud = (pud_t *)p4d_page_vaddr(*p4d) + pud_index(address); According to our memory model the compiler/CPU is free to execute this as: p4d = p4d_offset(pgd, addr) p4d_for_vaddr = *p4d; if (!p4d_present(*p4d)) return NULL; pud = (pud_t *)p4d_page_vaddr(p4d_for_vaddr) + pud_index(address); In the case where p4 goes from !present -> present (ie handle_mm_fault()): p4d_for_vaddr == p4d_none, and p4d_present(*p4d) == true, meaning the p4d_page_vaddr() will crash. Basically the problem here is not just missing READ_ONCE, but that the p4d is read multiple times at all. It should be written like gup_fast does, to guarantee a single CPU read of the unstable data: p4d = READ_ONCE(*p4d_offset(pgdp, addr)); if (!p4d_present(p4)) return NULL; pud = pud_offset(&p4d, addr); At least this is what I've been able to figure out :\ > > Also, the remark about pmd_offset() seems accurate. The > > get_user_fast_pages() pattern seems like the correct one to emulate: > > > > pud = READ_ONCE(*pudp); > > if (pud_none(pud)) > > .. > > if (!pud_'is a pmd pointer') > > .. > > pmdp = pmd_offset(&pud, address); > > pmd = READ_ONCE(*pmd); > > [...] > > > > Passing &pud in avoids another de-reference of the pudp. Honestly all > > these APIs that take in page table pointers and internally > > de-reference them seem very hard to use correctly when the page table > > access isn't fully locked against write. And the same protocol for the PUD, etc. > > It looks like at least the p4d read from the pgd is also unlocked here > > as handle_mm_fault() writes to it?? > > Yes, there is no locking required to call huge_pte_offset(). None? Not RCU or read mmap_sem? Jason