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=ham 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 552A6C4360F for ; Thu, 14 Feb 2019 21:39:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2EE3821B68 for ; Thu, 14 Feb 2019 21:39:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2440441AbfBNVj2 (ORCPT ); Thu, 14 Feb 2019 16:39:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36116 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2438205AbfBNVj0 (ORCPT ); Thu, 14 Feb 2019 16:39:26 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1AD2A7A48C; Thu, 14 Feb 2019 21:39:26 +0000 (UTC) Received: from redhat.com (unknown [10.20.6.236]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8A9535ED22; Thu, 14 Feb 2019 21:39:24 +0000 (UTC) Date: Thu, 14 Feb 2019 16:39:22 -0500 From: Jerome Glisse To: Matthew Wilcox Cc: Jason Gunthorpe , Dan Williams , Jan Kara , Dave Chinner , Christopher Lameter , Doug Ledford , Ira Weiny , lsf-pc@lists.linux-foundation.org, linux-rdma , Linux MM , Linux Kernel Mailing List , John Hubbard , Michal Hocko Subject: Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA Message-ID: <20190214213922.GD3420@redhat.com> References: <01000168c8e2de6b-9ab820ed-38ad-469c-b210-60fcff8ea81c-000000@email.amazonses.com> <20190208044302.GA20493@dastard> <20190208111028.GD6353@quack2.suse.cz> <20190211102402.GF19029@quack2.suse.cz> <20190211180654.GB24692@ziepe.ca> <20190214202622.GB3420@redhat.com> <20190214205049.GC12668@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190214205049.GC12668@bombadil.infradead.org> User-Agent: Mutt/1.10.0 (2018-05-17) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 14 Feb 2019 21:39:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 14, 2019 at 12:50:49PM -0800, Matthew Wilcox wrote: > On Thu, Feb 14, 2019 at 03:26:22PM -0500, Jerome Glisse wrote: > > On Mon, Feb 11, 2019 at 11:06:54AM -0700, Jason Gunthorpe wrote: > > > But it also doesnt' trucate/create a hole. Another thread wrote to it > > > right away and the 'hole' was essentially instantly reallocated. This > > > is an inherent, pre-existing, race in the ftrucate/etc APIs. > > > > So it is kind of a // point to this, but direct I/O do "truncate" pages > > or more exactly after a write direct I/O invalidate_inode_pages2_range() > > is call and it will try to unmap and remove from page cache all pages > > that have been written too. > > Hang on. Pages are tossed out of the page cache _before_ an O_DIRECT > write starts. The only way what you're describing can happen is if > there's a race between an O_DIRECT writer and an mmap. Which is either > an incredibly badly written application or someone trying an exploit. I believe they are tossed after O_DIRECT starts (dio_complete). But regardless the issues is that an RDMA can have pin the page long before the DIO in which case the page can not be toss from the page cache and what ever is written to the block device will be discarded once the RDMA unpin the pages. So we would end up in the code path that spit out big error message in the kernel log. Cheers, Jérôme