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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3DBEC77B78 for ; Tue, 2 May 2023 19:37:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3235C900003; Tue, 2 May 2023 15:37:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D50A900002; Tue, 2 May 2023 15:37:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 19BAE900003; Tue, 2 May 2023 15:37:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by kanga.kvack.org (Postfix) with ESMTP id BC146900002 for ; Tue, 2 May 2023 15:37:06 -0400 (EDT) Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-3f192c23fffso26504355e9.3 for ; Tue, 02 May 2023 12:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683056226; x=1685648226; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=yAN6Tx0XQ5cbgXparCHR/XEVN6lZoL4POmuLsxZAKdE=; b=k8kErdOPVqPjXe1UVr8CE/r8s1h4neD6cqHotJu9TowY8FOBIbOn+5Ho9ZTcDCagRk /XQzmVQnTYSOtm4WXN+YcYgnIVypug7+S+yvYzavsLrJJaDl3qd8/9WwOTa/UoKghyGo NUlKZ6xBdsjrqeAlsaefz8tdfEVcA6NFDLZ5vh3zQUugFLoVs+e+0KHh9Lrp3le77uTF FVOS0g558WHu+VX3dSGsRy5SrfkcF3tIGvfwKbSTagyG/arJM13RThshZmv2XxHYpwAC AP9tdMAwmJwBH5VsPgI5xQ+ODO651sEuQ2Yj/V01JnjkBFUmuaF4qQDQuDmFV7hJ67aX LcPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683056226; x=1685648226; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yAN6Tx0XQ5cbgXparCHR/XEVN6lZoL4POmuLsxZAKdE=; b=NSHKy+x3LFXUbCTp0zjA4cUgAiAdzq3uo3ZK3PdiF3Y+VdhrUe5lFwXOlQWHx8paof Y1rDU+0GGJPdMYTeNtGFbhMzXhcYPlddMd3RL0DfPxWeFAXezBOL+L6v+TpgsOOILMrW dM+7kMVTPUVseFRLLSqDf+uGaYlx+BFdP7wNmUuX7ByGjphKJcwNT8Q3DQjVJ3RC29up 6XvUc0CKqM6rmffcBFAZOhblFh6sstceGAqf8JOMjk3RpWQ2X0MYeurJbHwrzrGkMukO 7CQ1AqtrniWYomrXIZ0d86jnlICzOPSYT1lVmEi/CBzor3BZuJn3bIl4TNFd+ORk+wM4 MMQw== X-Gm-Message-State: AC+VfDy9v7dFNe0ISOWO/lhVs6OiQtwLekqsvJ5veebkbrSBYS0OjIge qNuTx8msAOVbb2GPJc024IY= X-Google-Smtp-Source: ACHHUZ7A2jMMtWzk7T9cgrRfNHzt/pitx4iisIgGusHr6EWYS363YI6sIGUZvgHUP7w7dxyOLghViw== X-Received: by 2002:a1c:7907:0:b0:3f1:8ef0:7e2f with SMTP id l7-20020a1c7907000000b003f18ef07e2fmr12767978wme.25.1683056225811; Tue, 02 May 2023 12:37:05 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id t24-20020a1c7718000000b003f3195be0a0sm16618019wmi.31.2023.05.02.12.37.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 May 2023 12:37:05 -0700 (PDT) Date: Tue, 2 May 2023 20:37:04 +0100 From: Lorenzo Stoakes To: David Hildenbrand Cc: Jason Gunthorpe , Peter Zijlstra , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Jens Axboe , Matthew Wilcox , Dennis Dalessandro , Leon Romanovsky , Christian Benvenuti , Nelson Escobar , Bernard Metzler , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , Bjorn Topel , Magnus Karlsson , Maciej Fijalkowski , Jonathan Lemon , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Christian Brauner , Richard Cochran , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, Oleg Nesterov , John Hubbard , Jan Kara , "Kirill A . Shutemov" , Pavel Begunkov , Mika Penttila , Dave Chinner , Theodore Ts'o , Peter Xu , Matthew Rosato , "Paul E . McKenney" , Christian Borntraeger , Mike Rapoport Subject: Re: [PATCH v7 3/3] mm/gup: disallow FOLL_LONGTERM GUP-fast writing to file-backed mappings Message-ID: References: <1691115d-dba4-636b-d736-6a20359a67c3@redhat.com> <20230502172231.GH1597538@hirez.programming.kicks-ass.net> <406fd43a-a051-5fbe-6f66-a43f5e7e7573@redhat.com> <3a8c672d-4e6c-4705-9d6c-509d3733eb05@lucifer.local> <968fa174-6720-4adf-9107-c777ee0d8da4@lucifer.local> <434c60e6-7ac4-229b-5db0-5175afbcfff5@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <434c60e6-7ac4-229b-5db0-5175afbcfff5@redhat.com> 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 Tue, May 02, 2023 at 09:33:45PM +0200, David Hildenbrand wrote: > On 02.05.23 21:25, Lorenzo Stoakes wrote: > > On Tue, May 02, 2023 at 04:07:50PM -0300, Jason Gunthorpe wrote: > > > On Tue, May 02, 2023 at 07:17:14PM +0100, Lorenzo Stoakes wrote: > > > > > > > On a specific point - if mapping turns out to be NULL after we confirm > > > > stable PTE, I'd be inclined to reject and let the slow path take care of > > > > it, would you agree that that's the correct approach? > > > > > > I think in general if GUP fast detects any kind of race it should bail > > > to the slow path. > > > > > > The races it tries to resolve itself should have really safe and > > > obvious solutions. > > > > > > I think this comment is misleading: > > > > > > > + /* > > > > + * GUP-fast disables IRQs - this prevents IPIs from causing page tables > > > > + * to disappear from under us, as well as preventing RCU grace periods > > > > + * from making progress (i.e. implying rcu_read_lock()). > > > > > > True, but that is not important here since we are not reading page > > > tables > > > > > > > + * This means we can rely on the folio remaining stable for all > > > > + * architectures, both those that set CONFIG_MMU_GATHER_RCU_TABLE_FREE > > > > + * and those that do not. > > > > > > Not really clear. We have a valid folio refcount here, that is all. > > > > Some of this is a product of mixed signals from different commenters and > > my being perhaps a little _too_ willing to just go with the flow. > > > > With interrupts disabled and IPI blocked, plus the assurances that > > interrupts being disabled implied the RCU version of page table > > manipulation is also blocked, my understanding was that remapping in this > > process to another page could not occur. > > > > Of course the folio is 'stable' in the sense we have a refcount on it, but > > it is unlocked so things can change. > > > > I'm guessing the RCU guarantees in the TLB logic are not as solid as IPI, > > because in the IPI case it seems to me you couldn't even clear the PTE > > entry before getting to the page table case. > > > > Otherwise, I'm a bit uncertain actually as to how we can get to the point > > where the folio->mapping is being manipulated. Is this why? > > I'll just stress again that I think there are cases where we unmap and free > a page without synchronizing against GUP-fast using an IPI or RCU. OK that explains why we need to be careful. Don't worry I am going to move the check after we confirm PTE entry hasn't changed. > > That's one of the reasons why we recheck if the PTE changed to back off, so > I've been told. > > I'm happy if someone proves me wrong and a page we just (temporarily) pinned > cannot have been freed+reused in the meantime. Let's play it safe for now :) > > -- > Thanks, > > David / dhildenb >