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 E3048C77B76 for ; Sun, 23 Apr 2023 20:02:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229603AbjDWUCZ (ORCPT ); Sun, 23 Apr 2023 16:02:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229473AbjDWUCY (ORCPT ); Sun, 23 Apr 2023 16:02:24 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C098E63; Sun, 23 Apr 2023 13:02:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 28D4D60F77; Sun, 23 Apr 2023 20:02:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD654C433D2; Sun, 23 Apr 2023 20:02:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682280142; bh=MXq/43kCze2RO9lP4ptWyt16cAC97gbSKdjUyiZkGe0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TeydC14vXjAcezSvOpLJ6lAgoD7kv4M6u2qpkMik63uNVRdyPydMRXOgOZl8horI+ dPMUTeoPcKNY3usBHvTn9wt3MN+OugsRnGr0IsC1oFmhWdpfSaV1Z2ZOlTUucNyFnI Dc7xJ3MsVgfv/9IzUKl8JIOxIGjmFLwo53Sw9q11W9QUhGzAN8aJtxFQ6cy32G+/6J sPWBqLbzeBzmMfJt637Yg3UjirQwtj3SDotLldKjhF9Q47+El15XA9ePt5cvIKvHTl ZLtLr/8hQ5GEStE0bg3XDleDq07tryjP50bYayKFt8JtmZOdkh1eS+Qu0bUY77irUf 0LMKZJajGU/pQ== Date: Sun, 23 Apr 2023 22:02:11 +0200 From: Simon Horman To: Lorenzo Stoakes Cc: Simon Horman , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Jason Gunthorpe , 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 Subject: Re: [PATCH] mm/gup: disallow GUP writing to file-backed mappings by default Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Sun, Apr 23, 2023 at 08:40:53PM +0100, Lorenzo Stoakes wrote: > On Sun, Apr 23, 2023 at 09:32:01PM +0200, Simon Horman wrote: > > On Sat, Apr 22, 2023 at 02:37:05PM +0100, Lorenzo Stoakes wrote: > > > It isn't safe to write to file-backed mappings as GUP does not ensure that > > > the semantics associated with such a write are performed correctly, for > > > instance filesystems which rely upon write-notify will not be correctly > > > notified. > > > > > > There are exceptions to this - shmem and hugetlb mappings are (in effect) > > > anonymous mappings by other names so we do permit this operation in these > > > cases. > > > > > > In addition, if no pinning takes place (neither FOLL_GET nor FOLL_PIN is > > > specified and neither flags gets implicitly set) then no writing can occur > > > so we do not perform the check in this instance. > > > > > > This is an important exception, as populate_vma_page_range() invokes > > > __get_user_pages() in this way (and thus so does __mm_populate(), used by > > > MAP_POPULATE mmap() and mlock() invocations). > > > > > > There are GUP users within the kernel that do nevertheless rely upon this > > > behaviour, so we introduce the FOLL_ALLOW_BROKEN_FILE_MAPPING flag to > > > explicitly permit this kind of GUP access. > > > > > > This is required in order to not break userspace in instances where the > > > uAPI might permit file-mapped addresses - a number of RDMA users require > > > this for instance, as do the process_vm_[read/write]v() system calls, > > > /proc/$pid/mem, ptrace and SDT uprobes. Each of these callers have been > > > updated to use this flag. > > > > > > Making this change is an important step towards a more reliable GUP, and > > > explicitly indicates which callers might encouter issues moving forward. > > > > nit: s/encouter/encounter/ > > > > Ack, I always seem to leave at least one or two easter egg spelling > mistakes in :) :) > Will fix up on next respin (in unlikely event of no further review, > hopefully Andrew would pick up!) >