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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B076DC6FA82 for ; Fri, 23 Sep 2022 08:39:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229983AbiIWIjr (ORCPT ); Fri, 23 Sep 2022 04:39:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48066 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229934AbiIWIjq (ORCPT ); Fri, 23 Sep 2022 04:39:46 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E44D82C669; Fri, 23 Sep 2022 01:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=V1rRq3lqNoW5TcE/xufv462Ekykzam6103C+3ht2Ez0=; b=nJejs3bRso0/zXedtRupWJU72A D3mRvV1bNdE2jDqNQcPlaka+ZwzpBWGS5HALHhg96r/Xp9OkKYfxPZYX4J3P+AbEbEuE2fbiu5w2q OswO4Rg7IAV6ekjzj5XIhzHzkgwzwTDKamCK8uJ1uCrwR//u5idtB2/UT1b11j2E7/5jb61SIPgEt fMKj4ZhqXR7WVWpg8ZeafRMkrxjAbjvm21zfVvJTbzz1AsoVx7wjyA79kn1mhGhQPBjPgOEOc4tKM kOVN+tMXAAJ30PeiPypcGFxGeX+CNxeYmzxe6HJiJe6T7SD4E1F1E45QfBGkRMXYGwstHf7BwLD7F Oa6WIohQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1obeDT-0030o0-Un; Fri, 23 Sep 2022 08:39:23 +0000 Date: Fri, 23 Sep 2022 01:39:23 -0700 From: Christoph Hellwig To: John Hubbard Cc: Al Viro , Jan Kara , Christoph Hellwig , Andrew Morton , Jens Axboe , Miklos Szeredi , "Darrick J . Wong" , Trond Myklebust , Anna Schumaker , David Hildenbrand , Logan Gunthorpe , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-nfs@vger.kernel.org, linux-mm@kvack.org, LKML Subject: Re: [PATCH v2 4/7] iov_iter: new iov_iter_pin_pages*() routines Message-ID: References: <20220914145233.cyeljaku4egeu4x2@quack3> <20220915081625.6a72nza6yq4l5etp@quack3> <20220922112935.pep45vfqfw5766gq@quack3> <7e652ba4-8b03-59e0-a9ef-1118c4bbd492@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e652ba4-8b03-59e0-a9ef-1118c4bbd492@nvidia.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org On Thu, Sep 22, 2022 at 09:05:16PM -0700, John Hubbard wrote: > I certainly hope not. And in fact, we should really just say that that's > a rule: the whole time the page is pinned, it simply must remain dirty > and writable, at least with the way things are right now. Yes, if we can stick to that rule and make sure shared pagecache is never dirtied through get_user_pags anywhere that will allow us to fix a lot of mess > To fix those cases, IIUC, the answer is: you must make the page dirty > properly, with page_mkwrite(), not just with set_page_dirty_lock(). And > that has to be done probably a lot earlier, for reasons that I'm still > vague on. But perhaps right after pinning the page. (Assuming that we > hold off writeback while the page is pinned.) I think we need to hold off the writeback for it to work properly. The big question is, is if there are callers that do expect data to be written back on mappings that are longterm pinned. RDMA or vfio would come to mind.