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 799A0C77B73 for ; Mon, 24 Apr 2023 12:38:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231249AbjDXMiw (ORCPT ); Mon, 24 Apr 2023 08:38:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229696AbjDXMiv (ORCPT ); Mon, 24 Apr 2023 08:38:51 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E7D42D48; Mon, 24 Apr 2023 05:38:50 -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=5OALIrDldLQfwHP9p2ndyFBK2lC4EsP1Af7zzRq70HI=; b=oxHS7/offNNywVCnbgn859E+Z8 SYCfU4xYyhNEUEds393rO5wINqj82AoYAyZTELk7z80VjU8UPitXrHw03lV+WplVb4yALgivN41pN 3aAEc5YC9KzREtP9upgcMYQc0N1KKAPLZ+z7FvfV1ViOfdWkXk1T7ngxz+2iNiYxm3PlS21Uq1hoM TtTu0HzL22OV0k6O9ljV5DFyhahABI4iimBMUVndpCMvOixeI4d5PXXRr7csMwBevz9x4TWq6CjF7 5Alb3RSlH+Df1e2w7PqY2OImD79V0gvwKqS0t9scRcDw3V5AaSCNlNNQmQoVgNsajPeCH4lVvFWrB HpqlZJjQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1pqvSu-00GKZp-1o; Mon, 24 Apr 2023 12:38:44 +0000 Date: Mon, 24 Apr 2023 05:38:44 -0700 From: Christoph Hellwig To: Jason Gunthorpe Cc: Lorenzo Stoakes , Christoph Hellwig , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Jens Axboe , Matthew Wilcox , Dennis Dalessandro , Leon Romanovsky , Christian Benvenuti , Nelson Escobar , Bernard Metzler , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , Bjorn Topel , Magnus Karlsson , Maciej Fijalkowski , Jonathan Lemon , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Christian Brauner , Richard Cochran , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, Oleg Nesterov , Jan Kara , Chris Mason , John Hubbard Subject: Re: [PATCH v2] mm/gup: disallow GUP writing to file-backed mappings by default Message-ID: References: <90a54439-5d30-4711-8a86-eba816782a66@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-perf-users@vger.kernel.org On Mon, Apr 24, 2023 at 09:28:07AM -0300, Jason Gunthorpe wrote: > On Mon, Apr 24, 2023 at 11:17:55AM +0100, Lorenzo Stoakes wrote: > > On Mon, Apr 24, 2023 at 02:43:56AM -0700, Christoph Hellwig wrote: > > > I'm pretty sure DIRECT I/O reads that write into file backed mappings > > > are out there in the wild. > > I wonder if that is really the case? I know people tried this with > RDMA and it didn't get very far before testing uncovered data > corruption and kernel crashes.. Maybe O_DIRECT has a much smaller race > window so people can get away with it? It absolutely causes all kinds of issues even with O_DIRECT. I'd be all for trying to disallow it as it simplies a lot of things, but I fear it's not going to stick. > So, my suggestion was to mark the places where we want to allow this, > eg O_DIRECT, and block everwhere else. Lorenzo, I would significantly > par back the list you have. I think an opt-in is a good idea no matter how many places end up needing it. I'd prefer a less dramatic name and a better explanation on why it should only be set when needed. > I also suggest we force block it at some kernel lockdown level.. > > Alternatively, perhaps we abuse FOLL_LONGTERM and prevent it from > working with filebacked pages since, I think, the ease of triggering a > bug goes up the longer the pages are pinned. FOLL_LONGTERM on file backed pages is a nightmare. If you think you can get away with prohibiting it for RDMA, and KVM doesn't need it I'd be all for not allowing that at all.