Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8902983ybi; Tue, 23 Jul 2019 17:44:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqxVtzX2xq5PMzzOniMvZ04V1/oIRxEr+As+LHKWPCpILV40JEx9r0EnPJACTCuSpBhCBcyM X-Received: by 2002:a17:90a:9505:: with SMTP id t5mr84173796pjo.96.1563929094858; Tue, 23 Jul 2019 17:44:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563929094; cv=none; d=google.com; s=arc-20160816; b=t7Kdp9atcOEmDE7As6QUGDRbq5OBbNfoJiGnLDHckr+OwEyRxGcKBUoMsSt8/qZ8Dq qsjvOTC22n2vBUmcCdsj2sqFHSxEqjgyTtcSYCNc9Y0YP44XCudDnKLE1gtG5oRpYUuB bZG71/AczCzmAevgsRu1YoTTPnRnQ9vR6HGMq+xGKxwKRGXwqIPmHiKvfZTfOIZKarur Py+PyJs57WnQUk7IoBAVEMtBT0nMA41rdDgixoq47Y9dhHN0amKEPUPOiWCZlCnSTOlR UdQRu7xc9860inuBRfOvzwClDrbeOV4EIC3+fLDXAiMxsswgtuKSmgBsYbUbxAoqp8o7 8e4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=frxfWSpefKxGEUFD2kmnWKrXpcu24CFEk0ZgQ6qgIQ8=; b=nBMp+u7oFeKn/yoklaAohfJLIL0oiKeVIsCs4mIiL5lOqUzjf8d9BoF35bazoYlWd3 Rijr9BQNXLtgPScbkIrifSfsM6q90+DquWIEb4MG41Xix8g6LnRt/cA7SPkJ4ykIsK/v E8GmU+ipmiBAmmz9asWwTs1khiJ0l1OMVM/Ufl89skWD+7bA83SxqCD+G8qa3a6fciBS IxZEQ+9f8xcKAqlakC2iEJFlu1H1ulqoqsZ7NdpOEdjCVCX90cZRVPaV4uiV8eGWhnGv wYfxiRNLQr7KJhcpt7VB5XPovtnFatke/t/w601s92E3mLYQE+2RI+TwAxjKIRDXq2Nj 3Gwg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x22si11848984pln.150.2019.07.23.17.44.38; Tue, 23 Jul 2019 17:44:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387834AbfGWPgo (ORCPT + 99 others); Tue, 23 Jul 2019 11:36:44 -0400 Received: from verein.lst.de ([213.95.11.211]:42749 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726432AbfGWPgo (ORCPT ); Tue, 23 Jul 2019 11:36:44 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id A348468B02; Tue, 23 Jul 2019 17:36:40 +0200 (CEST) Date: Tue, 23 Jul 2019 17:36:40 +0200 From: Christoph Hellwig To: John Hubbard Cc: Christoph Hellwig , john.hubbard@gmail.com, Andrew Morton , Alexander Viro , =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= , Boaz Harrosh , Daniel Vetter , Dan Williams , Dave Chinner , David Airlie , "David S . Miller" , Ilya Dryomov , Jan Kara , Jason Gunthorpe , Jens Axboe , =?iso-8859-1?B?Suly9G1l?= Glisse , Johannes Thumshirn , Magnus Karlsson , Matthew Wilcox , Miklos Szeredi , Ming Lei , Sage Weil , Santosh Shilimkar , Yan Zheng , netdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-mm@kvack.org, linux-rdma@vger.kernel.org, bpf@vger.kernel.org, LKML Subject: Re: [PATCH 1/3] mm/gup: introduce __put_user_pages() Message-ID: <20190723153640.GB720@lst.de> References: <20190722223415.13269-1-jhubbard@nvidia.com> <20190722223415.13269-2-jhubbard@nvidia.com> <20190723055359.GC17148@lst.de> <8ab4899c-ec12-a713-cac2-d951fff2a347@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ab4899c-ec12-a713-cac2-d951fff2a347@nvidia.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 22, 2019 at 11:33:32PM -0700, John Hubbard wrote: > I'm seeing about 18 places where set_page_dirty() is used, in the call site > conversions so far, and about 20 places where set_page_dirty_lock() is > used. So without knowing how many of the former (if any) represent bugs, > you can see why the proposal here supports both DIRTY and DIRTY_LOCK. Well, it should be fairly easy to audit. set_page_dirty() is only safe if we are dealing with a file backed page where we have reference on the inode it hangs off. Which should basically be never or almost never.