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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50E37C77B7C for ; Mon, 17 Apr 2023 14:00:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F7FB6B0071; Mon, 17 Apr 2023 10:00:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A80A6B0072; Mon, 17 Apr 2023 10:00:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 649D28E0001; Mon, 17 Apr 2023 10:00:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 562F96B0071 for ; Mon, 17 Apr 2023 10:00:22 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id F02BA1C6569 for ; Mon, 17 Apr 2023 14:00:21 +0000 (UTC) X-FDA: 80691042642.02.CFCCCB2 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by imf01.hostedemail.com (Postfix) with ESMTP id 009D440023 for ; Mon, 17 Apr 2023 14:00:18 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=XiRteR7I; spf=pass (imf01.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681740019; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=As3N+DrtQ6raqrH+805ObsScr0Zt0AbJ2ISLA6BSiDM=; b=EHisHQOTbgG08UjtFsDtgj0VtNC+6x7H5boYLJvVqXrU7tWT/WbG8oOxDDrSj2htC3Ogqr s19QFtgjG9j5wP/JwIemZ93ztdRTeqMiRXNzheQfUaqMFfCC6Cgf0S/Djm+6s0akPBGHzp ngatnSeD3KMkKxhpVpX6+HwESjs3LwY= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=XiRteR7I; spf=pass (imf01.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681740019; a=rsa-sha256; cv=none; b=viiBvM7jDKXL+lwfg05a6NpouzFvwSae8q0XOt2vtDwj8w9oNTr9qhyhP5gH7v2jCfpLtP LIn8ZlpHWcs4XFjzplIpHU2w0mndgrb1PwAlnG0InrtTr/q0GLAH11/3UqBIisr5NKHuOK +qld9q3P/bQvmHsoWDU4R06+Mh8oK18= Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-3f167d0c91bso15966865e9.2 for ; Mon, 17 Apr 2023 07:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681740017; x=1684332017; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=As3N+DrtQ6raqrH+805ObsScr0Zt0AbJ2ISLA6BSiDM=; b=XiRteR7Ir6ZKovA5xtpgeeFnixoor8e5OJSllcyrZ1m6UXKkhh6iHCSCKd+ZqlxSRR SKhU70WNrmfyT71ZaCV3HCK33LnWTF3Ht9qHcNEdvR+dRpS9Y9Q0XN6y/a7UELhKsFOQ McRbVli/j+H15T9ZmtNWS3RKpZBjfDBjgo7LtAE1QPuyskfnYsMiYZUXxc6WC1FFzo1x CyTp6QW5tDAT4b+1G7YQFsBeApgHVckABjCayp5XAihH2l73erS2C/Aa6E6gIiLZMhL8 IQskqIKSr945UHhgcazXBUQpDhs78U0hyvGAVlryLXiU0Dg+QfXeEbSaKuOqAs8D3qhy Br4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681740017; x=1684332017; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=As3N+DrtQ6raqrH+805ObsScr0Zt0AbJ2ISLA6BSiDM=; b=QApbGZ0uNzPP9bfa+Bo+HKBnJVxyFI6AOHwWkN8HRWQxtOpaLbTjUIJHEFcnjZoZGA BIBEaxxfnh6GG9sbnLRUJOrIrXCMfAkBrc4vmX0fmFwNfJRr2Idso97yQ6rmVUvhYyB7 KvhQ0fhc8v8GwDqS0PX8uJd070ZihFQBC6cmeLM7nQoMC9NVbT6azuaG6z6TH09oN3+w ubdsedqhQpbr12RGUjrQzPFipQ+QRxVCn/LASy5XUdUN6zg8UMIYZ1p0Yho3ttV1WR9K peFoyR/q1zOwcqfdDJ3GKVQLiVLvkdnIQoRGIvOMfQuFchWZXiWzE0apITnMIiQo7ViC YLlA== X-Gm-Message-State: AAQBX9fGJ2/Bryq8wU4ViYN8xqNHhZbdawE3L1P3uHp/19yv6UGCiUtv iuhUcK+NLRJ01yLehqgQ5MpG7lrRijSGng== X-Google-Smtp-Source: AKy350aSnN4JtWypJ7B0dqpvH50sKAnXYTSDJAB1Uef+tD6SGnbDa8WcWX7WPcYUZoF0Mqmbj7FCsw== X-Received: by 2002:a5d:410c:0:b0:2f0:dfd4:7f49 with SMTP id l12-20020a5d410c000000b002f0dfd47f49mr4916966wrp.26.1681740017372; Mon, 17 Apr 2023 07:00:17 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id y11-20020a056000108b00b002f013fb708fsm10671449wrw.4.2023.04.17.07.00.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Apr 2023 07:00:16 -0700 (PDT) Date: Mon, 17 Apr 2023 15:00:16 +0100 From: Lorenzo Stoakes To: Jason Gunthorpe Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Matthew Wilcox , David Hildenbrand , Jens Axboe , Pavel Begunkov , io-uring@vger.kernel.org Subject: Re: [PATCH 5/7] io_uring: rsrc: use FOLL_SAME_FILE on pin_user_pages() Message-ID: <34959b70-6270-46cf-94c5-d6da12b0c62d@lucifer.local> References: <17357dec04b32593b71e4fdf3c30a346020acf98.1681508038.git.lstoakes@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 009D440023 X-Stat-Signature: mswhmsk58ebh8zohp3zi1ermf1p5oy5k X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1681740018-991268 X-HE-Meta: U2FsdGVkX1/jCQOtyaBJ9/9DH6obVcZV2jLC87MkSjDIGVzMPRneRpi0OpcoUOjYjBVZCLNZNPnwtCIgyEnlbzrPJjQ3jBhts53fuY72w9OWFj69qsmqhTCH13YIT9ldU9AR0sam36qRUlTEtHBfHWn+xJTi50Fd+d1oCL0b5RZzjTWJi4chTtp0AICQgn+BA0VylD/PDOkyVsMdaSRP+JPWYU+WPCIgZqhEqEw5+esNo5vEOUzBOBBRwG9cK/ILf6KlBJdjhpJF73BVNfTMEUvt5bkQ6u/DuVeFdlDUPcDdMKb9/qB+rZAX85Q988Hm3NTC9vwUSDItaD6uEje6znLLqT0SrZkOAosyZTkx/e+k9AZgNnQY7qy5Wj72MymfUNs5Bsfy872iFwn/cH7CW7zMHR01IvwCaJq+MbHAeyyLmmfKDUEBeC3Pf5fHhN+T6sN1YpeCdprqEWus2w61okoIByCYvtf8KWePpqueGxFN74ls1c7z9PrXBlcL6vktBbadhEBbzuVqC5pUuL6Z9M7zTBVBzXX4aGqHxCOlW6p0JB/ZrRe+JWz0EjF0vwWXSAUuhSBZOlldJHubb2H/1i6iOzf9LbABlbfqzZmsIm14NxiEemb6Q0NJKWu92biMTbHEazjsAMR1UWGNoRw/U2xNjgA9VVPSp4g84clj3Ke6XfrqCrD5Uwl2wcvJglX7di1852QVHw9Z78p3ZHfMVNgq76e72f1NVifsNgM4rfAqB1iA4rLUdB5N8vfdVkqVbLquYOkqZzGsPJ/qLDq6q4pkTpKhQr3+ts6NADvsWZ4vkr2Xbj2zoe4CRI7PJ01xBKhMvvrx2B31JANSJpOJ8+reKvhRYlHX+m5+mmebtrYpyT4nwd8LTzgzaktG/p8grG7xCJkaQrwzaJOpI5IUJXY+508tqIkSeRGTPKrkTwoQy+bWKohHCdnvprwZ0dzE2tm372DxJjsh7gx/N0x FDfG8rQt IlqBQX80F7MlIAwq9ASlRX9EZP+LssWhZ6dcQp93zYSFE2MLl4KEX4wtmDcTLR3LDdA4xA4GLWk/i+m24zrkycXw01zswyNTEmVNM+4vSd2LEHe/O1IhWpo4a41nKvh3UXyhkAGWGVo9TBWwm+g1xo+U2DHws4n8P7SW90/vHMVG5frmoXdYIPpMC2/6ICkf0YvQilB1ZpO+DOOZMs5OctizKZtYf7pyZzBcNwsj/i7e8cmQP05qPnpHA0vnGR/WtQ74LH02Tl7n5sgEodqZo8HFRoRs+RkQ7NXymHlhRrCnIfwCjv7uw5MkqOXBQ9+gR7FRRGNgL7sumtfAqf2/q3h4Okn68egn2bQZUC8vtAXCgodwV2XpBNde3KlmtZAxevvzs1ppFGANyBYxH47BH9HNw3WB3tmIC3q8329LQ7dFqpo5lpTHlZYBpc+VXYtdPtg/ChbarzXc8KfBzy44SoOSpusjKZdoICo2YPr15eiRJuqquNJMW0PfSObG/fHOModACG8tr4TBhChvAxzU4ZfbXmg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.041592, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Apr 17, 2023 at 10:26:09AM -0300, Jason Gunthorpe wrote: > On Mon, Apr 17, 2023 at 02:19:16PM +0100, Lorenzo Stoakes wrote: > > > > I'd rather see something like FOLL_ALLOW_BROKEN_FILE_MAPPINGS than > > > io_uring open coding this kind of stuff. > > > > > > > How would the semantics of this work? What is broken? It is a little > > frustrating that we have FOLL_ANON but hugetlb as an outlying case, adding > > FOLL_ANON_OR_HUGETLB was another consideration... > > It says "historically this user has accepted file backed pages and we > we think there may actually be users doing that, so don't break the > uABI" Having written a bunch here I suddenly realised that you probably mean for this flag to NOT be applied to the io_uring code and thus have it enforce the 'anonymous or hugetlb' check by default? > > Without the flag GUP would refuse to return file backed pages that can > trigger kernel crashes or data corruption. > > Eg we'd want most places to not specify the flag and the few that do > to have some justification. > So you mean to disallow file-backed page pinning as a whole unless this flag is specified? For FOLL_GET I can see that access to the underlying data is dangerous as the memory may get reclaimed or migrated, but surely DMA-pinned memory (as is the case here) is safe? Or is this a product more so of some kernel process accessing file-backed pages for a file system which expects write-notify semantics and doesn't get them in this case, which could indeed be horribly broken. In which case yes this seems sensible. > We should consdier removing FOLL_ANON, I'm not sure it really makes > sense these days for what proc is doing with it. All that proc stuff > could likely be turned into a kthread_use_mm() and a simple > copy_to/from user? > > I suspect that eliminates the need to check for FOLL_ANON? > > Jason I am definitely in favour of cutting things down if possible, and very much prefer the use of uaccess if we are able to do so rather than GUP. I do feel that GUP should be focused purely on pinning memory rather than manipulating it (whether read or write) so I agree with this sentiment.