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.3 required=3.0 tests=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 603F6C7618B for ; Tue, 23 Jul 2019 15:36:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3CC1921734 for ; Tue, 23 Jul 2019 15:36:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726967AbfGWPgo (ORCPT ); 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-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 1/3] mm/gup: introduce __put_user_pages() Date: Tue, 23 Jul 2019 17:36:40 +0200 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 Return-path: Content-Disposition: inline In-Reply-To: <8ab4899c-ec12-a713-cac2-d951fff2a347@nvidia.com> Sender: linux-kernel-owner@vger.kernel.org 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 List-Id: dri-devel@lists.freedesktop.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.