From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions Date: Wed, 16 Jan 2019 12:38:19 +0100 Message-ID: <20190116113819.GD26069@quack2.suse.cz> References: <20190111165141.GB3190@redhat.com> <1b37061c-5598-1b02-2983-80003f1c71f2@nvidia.com> <20190112020228.GA5059@redhat.com> <294bdcfa-5bf9-9c09-9d43-875e8375e264@nvidia.com> <20190112024625.GB5059@redhat.com> <20190114145447.GJ13316@quack2.suse.cz> <20190114172124.GA3702@redhat.com> <20190115080759.GC29524@quack2.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , John Hubbard , Matthew Wilcox , Dave Chinner , Dan Williams , John Hubbard , Andrew Morton , Linux MM , tom@talpey.com, Al Viro , benve@cisco.com, Christoph Hellwig , Christopher Lameter , "Dalessandro, Dennis" , Doug Ledford , Jason Gunthorpe , Michal Hocko , mike.marciniszyn@intel.com, rcampbell@nvidia.com, Linux Kernel Mailing List , linux-fsdevel To: Jerome Glisse Return-path: Content-Disposition: inline In-Reply-To: <20190115080759.GC29524@quack2.suse.cz> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue 15-01-19 09:07:59, Jan Kara wrote: > Agreed. So with page lock it would actually look like: > > get_page_pin() > lock_page(page); > wait_for_stable_page(); > atomic_add(&page->_refcount, PAGE_PIN_BIAS); > unlock_page(page); > > And if we perform page_pinned() check under page lock, then if > page_pinned() returned false, we are sure page is not and will not be > pinned until we drop the page lock (and also until page writeback is > completed if needed). After some more though, why do we even need wait_for_stable_page() and lock_page() in get_page_pin()? During writepage page_mkclean() will write protect all page tables. So there can be no new writeable GUP pins until we unlock the page as all such GUPs will have to first go through fault and ->page_mkwrite() handler. And that will wait on page lock and do wait_for_stable_page() for us anyway. Am I just confused? That actually touches on another question I wanted to get opinions on. GUP can be for read and GUP can be for write (that is one of GUP flags). Filesystems with page cache generally have issues only with GUP for write as it can currently corrupt data, unexpectedly dirty page etc.. DAX & memory hotplug have issues with both (DAX cannot truncate page pinned in any way, memory hotplug will just loop in kernel until the page gets unpinned). So we probably want to track both types of GUP pins and page-cache based filesystems will take the hit even if they don't have to for read-pins? Honza -- Jan Kara SUSE Labs, CR 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.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 EDA41C43387 for ; Wed, 16 Jan 2019 11:38:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C180C20859 for ; Wed, 16 Jan 2019 11:38:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732454AbfAPLiW (ORCPT ); Wed, 16 Jan 2019 06:38:22 -0500 Received: from mx2.suse.de ([195.135.220.15]:55420 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731984AbfAPLiW (ORCPT ); Wed, 16 Jan 2019 06:38:22 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 675DEAE76; Wed, 16 Jan 2019 11:38:20 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 32EED1E1580; Wed, 16 Jan 2019 12:38:19 +0100 (CET) Date: Wed, 16 Jan 2019 12:38:19 +0100 From: Jan Kara To: Jerome Glisse Cc: Jan Kara , John Hubbard , Matthew Wilcox , Dave Chinner , Dan Williams , John Hubbard , Andrew Morton , Linux MM , tom@talpey.com, Al Viro , benve@cisco.com, Christoph Hellwig , Christopher Lameter , "Dalessandro, Dennis" , Doug Ledford , Jason Gunthorpe , Michal Hocko , mike.marciniszyn@intel.com, rcampbell@nvidia.com, Linux Kernel Mailing List , linux-fsdevel Subject: Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions Message-ID: <20190116113819.GD26069@quack2.suse.cz> References: <20190111165141.GB3190@redhat.com> <1b37061c-5598-1b02-2983-80003f1c71f2@nvidia.com> <20190112020228.GA5059@redhat.com> <294bdcfa-5bf9-9c09-9d43-875e8375e264@nvidia.com> <20190112024625.GB5059@redhat.com> <20190114145447.GJ13316@quack2.suse.cz> <20190114172124.GA3702@redhat.com> <20190115080759.GC29524@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190115080759.GC29524@quack2.suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Message-ID: <20190116113819.Zj6VC1ndTzqZjgx3vVbNHoTnBd4B-DOtVLvREX_OpfU@z> On Tue 15-01-19 09:07:59, Jan Kara wrote: > Agreed. So with page lock it would actually look like: > > get_page_pin() > lock_page(page); > wait_for_stable_page(); > atomic_add(&page->_refcount, PAGE_PIN_BIAS); > unlock_page(page); > > And if we perform page_pinned() check under page lock, then if > page_pinned() returned false, we are sure page is not and will not be > pinned until we drop the page lock (and also until page writeback is > completed if needed). After some more though, why do we even need wait_for_stable_page() and lock_page() in get_page_pin()? During writepage page_mkclean() will write protect all page tables. So there can be no new writeable GUP pins until we unlock the page as all such GUPs will have to first go through fault and ->page_mkwrite() handler. And that will wait on page lock and do wait_for_stable_page() for us anyway. Am I just confused? That actually touches on another question I wanted to get opinions on. GUP can be for read and GUP can be for write (that is one of GUP flags). Filesystems with page cache generally have issues only with GUP for write as it can currently corrupt data, unexpectedly dirty page etc.. DAX & memory hotplug have issues with both (DAX cannot truncate page pinned in any way, memory hotplug will just loop in kernel until the page gets unpinned). So we probably want to track both types of GUP pins and page-cache based filesystems will take the hit even if they don't have to for read-pins? Honza -- Jan Kara SUSE Labs, CR