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 4C131C77B7A for ; Wed, 17 May 2023 08:27:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C9E62900004; Wed, 17 May 2023 04:27:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C4EF6900003; Wed, 17 May 2023 04:27:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC9DE900004; Wed, 17 May 2023 04:27:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9C5DA900003 for ; Wed, 17 May 2023 04:27:05 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6CB7D804D1 for ; Wed, 17 May 2023 08:27:05 +0000 (UTC) X-FDA: 80799066810.01.6A36FB9 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf14.hostedemail.com (Postfix) with ESMTP id E9E2610000F for ; Wed, 17 May 2023 08:27:02 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Hdfs3Zyu; spf=pass (imf14.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684312023; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BhjK5yazou5RvTWn30tpmSdINFxSKMIDQ661jcxLjOE=; b=hx4kaMqf7jCjArXt4LgAuPaK3qG3m/eALcdqpYBUxgrE5VI+tqYVn0D083Y3E8upR+bA4+ r+gS/S1NzfoBbW9v316ua7zWAFNuNTbfKj7aidnliZqFZXo+3WHtB07rGB6rEi9bFgMqmR ftqxYQh647dfYkikX30ol4NiXqGR+ew= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684312023; a=rsa-sha256; cv=none; b=gpge8Ez30apB16X44bTfIBUHp9xMhK83pxTpQbdZ0bqB4/6nB4iDpwsJSnusfN8rLd7GLc bSoXTUmqbO/vheZHq2Tm7IR9UMyhvIqeLI2k3rMiev4Zk6kTX9+WEjFpgPexwxc9mhNhVC kegbbhxJQ2kfY98cc0tX3fbgIdVqCKo= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Hdfs3Zyu; spf=pass (imf14.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684312022; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BhjK5yazou5RvTWn30tpmSdINFxSKMIDQ661jcxLjOE=; b=Hdfs3ZyuzW17C5O28jpqFd56YDik0Ryg9x3VOJymCYphVmj3AduM7G5Os37yWIF7bkea9q 0nwj2utkmc0Q3PyObVwlECLImOOW63eShhFmoNj3mGxB2bqqkafNS/ZvzOOAw+j9fPgoG5 KMVzOQJSfUse2PNxPWvD2Cxow3OWDsA= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-674--GTHZbT1OS-WxpSi7aNdRA-1; Wed, 17 May 2023 04:27:00 -0400 X-MC-Unique: -GTHZbT1OS-WxpSi7aNdRA-1 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-3f429072212so2074415e9.1 for ; Wed, 17 May 2023 01:27:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684312019; x=1686904019; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BhjK5yazou5RvTWn30tpmSdINFxSKMIDQ661jcxLjOE=; b=ieM9uT62nQimOxWYDDICq4GUgJj/8o5jK9hj7x2ATADRoG303mcWTGh8Wz2TKc+Xo4 yoelX1e7oCvoLdETfiPSKmaRXicU2sDZ7WF6tBL+SvCObN1JeW2wYPT0Fhgg3KKvyPyH /qn815b6g2Vnvc1X+/xzE5260gJbQWijLQ6CE2cVKNmNWyrV8tshxFaUI8ooB0NP24M2 aT4MjvzRRJnnvFum9x8ETXK3ImqpFT5E8wP3rSUu8Im7zcxoCZkGwLPC49Ah1r0wA+YT HSBAuE9xw5ljZbFhbEy/mjVgMYg7qyDDT/KjmcngZRI2s9TW4ozCWNAPqAKSV24P3fZg VAkA== X-Gm-Message-State: AC+VfDwVokq6fHaLItJ21G0ZJAap15Bzw9GhUH4glyids0UcR+jgICYH BUQgo4+RiPa/L2KvmCAP2QiQE8/RzS9B6Hd2ffcvGXq5OOUnrIJy2uxoyo5z38JOjJDneKwYXuo qRZ1lNaNaoy0= X-Received: by 2002:a05:600c:2141:b0:3f4:fd67:6d7c with SMTP id v1-20020a05600c214100b003f4fd676d7cmr9063694wml.40.1684312019276; Wed, 17 May 2023 01:26:59 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5xa065nZ/uQiaIJKC7O793u58obHvly4Gk+TYkCEFKD9upiESKtIAlN64oMtp1eokU88QqYA== X-Received: by 2002:a05:600c:2141:b0:3f4:fd67:6d7c with SMTP id v1-20020a05600c214100b003f4fd676d7cmr9063676wml.40.1684312018895; Wed, 17 May 2023 01:26:58 -0700 (PDT) Received: from [192.168.3.108] (p4ff23b51.dip0.t-ipconnect.de. [79.242.59.81]) by smtp.gmail.com with ESMTPSA id a3-20020a05600c224300b003f17848673fsm1416580wmm.27.2023.05.17.01.26.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 May 2023 01:26:58 -0700 (PDT) Message-ID: <3c11455b-3af4-eeaa-9f43-49d4d70348fd@redhat.com> Date: Wed, 17 May 2023 10:26:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 To: Lorenzo Stoakes , Christoph Hellwig Cc: 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, Oleg Nesterov , Jason Gunthorpe , John Hubbard , Jan Kara , "Kirill A . Shutemov" , Pavel Begunkov , Mika Penttila , Dave Chinner , Theodore Ts'o , Peter Xu , Matthew Rosato , "Paul E . McKenney" , Christian Borntraeger References: <0eb31f6f-a122-4a5b-a959-03ed4dee1f3c@lucifer.local> <59c47ed5-a565-4220-823c-a278130092d5@lucifer.local> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v9 0/3] mm/gup: disallow GUP writing to file-backed mappings by default In-Reply-To: <59c47ed5-a565-4220-823c-a278130092d5@lucifer.local> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: dng4dh5t1sosa89jcdidqj14bi4h6r8x X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E9E2610000F X-Rspam-User: X-HE-Tag: 1684312022-507462 X-HE-Meta: U2FsdGVkX19AcvYKJLO4a8AhtX0QVjx3T19E/4o99BzXqon1gpDtRyKzBbVZ1v87Z9uJr7kjJ2oijj+0+05qbtiDIwxvaxTvwPzUnK8nnFPhvvgcRtev8SD7jfMG0W513i4qwH8zwI4wDc45BybfyqbrAOXalD/IAwyol+1Uc/r7jkL0AWMxdTcg3oWqyNnvfrIHVBtdsXbKZ6n+/cszPCDW/LYcs5Tx1545coz1CESAL0yBRk1ibf1iZpAZMXYpRvnP5Fb3bfb8bEluwNnjiYFurBw1nZgct0mTe+yDE5j/aOW8ZXLQnnbQ1M6qZs7XDM5El2UejtVEG9VZaXt+nUoWnuJFQ3HAs25kphmmfkidFtz3YhqUaVazHN1K1zfg/c+PTJAZosK9ynnzc2Jj1295JhjUKl2KZ30Sp2SOqxlp2hi0229C5iuIkuuBUx4uxH6lK5/bgZ62xBOJiuqDyQL0ud9Fhv1DSj0W6hT5+XIqDSZQOovTz+y/x64CcpOeQFlW6ji1s3/ka4xVIAnK1n93p14u05ENwAFjFI+EHkf6p4AjUk6l7oUgEIFvoeOaVpbyBjMFm7lQNrdhq46SZ5YGW/T+dTd8IYsW4XlQTm7WkvZEWqGoNhd2LPtJUIKiE7QTumBUR169nSmnMd0/OgxtyuXmIoXmy2umbiT/W8ev7myPO0mDTYMMsuMj+8yFsY/V0nqV1hUhv0fn1u5vekBqUSW31/CTjg96wU42ZBaYWQZ5XTgr1rq6dz8Jratlm4Oe69SC7IpVSaTYDKF1ZiJAPVge64KNJw+e3WPKPiYQCnZkClHOrJ4BICt/4YOV/2Yu6GlWRRjQMZPcASxkL03vsl8kKaps18i7zRseqIwTdOwfsegU8bD40HcjdVpf5mFu1VmdAKm05sVdsoQ7wz/I6nu7VW8NGo0BD2dYkoXewxViSQUYXwPV5B33X4UHJ5HJeHo8Nyu2gBhj4xe aLzxRu84 nxZBywVVYj+az9nzkixe0MXYAc6/kVAmBBdblIM899iX87Pm8LObJYNLwSIHsO8QEuekowre88le34fdvLC+MLQzKkC/E80PZjwjWUMmOmEYdfsGdHKglctgEdwU7kshRCozMpluMR6Xjb1BksASqkNez7b9F79NRU+qvaklJB/DQ4MzX+/UZEB3beJot2zokkhxzdZIGbyIkXhMZD7gwAYUzIqf8v0neGd+FJfrt2fKEd2JWL3A+1YHU4c08rCIxdpUwEreKfDqGS05TdOT436b3Uhxdw+3VmEGuE5YpbHE+QwLdVACLY1LR9X59RLY/cTzT93H8v+k/sag3+iLmhSEhjnaUA5F7seKDPLeYMFczld76zpSMhp6PyMXVPyxaEAp0tI1qWZwjH26EaIs+kM1QsRVFau35aFyhPYXMgcnde4vTJ5Hc6mqyWddi5DlEWlH/eX6brg902BU+w/23zH9TFWOi/Q8ljwPu X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 15.05.23 13:31, Lorenzo Stoakes wrote: > On Sun, May 14, 2023 at 10:14:46PM -0700, Christoph Hellwig wrote: >> On Sun, May 14, 2023 at 08:20:04PM +0100, Lorenzo Stoakes wrote: >>> As discussed at LSF/MM, on the flight over I wrote a little repro [0] which >>> reliably triggers the ext4 warning by recreating the scenario described >>> above, using a small userland program and kernel module. >>> >>> This code is not perfect (plane code :) but does seem to do the job >>> adequately, also obviously this should only be run in a VM environment >>> where data loss is acceptable (in my case a small qemu instance). >> >> It would be really awesome if you could wire it up with and submit it >> to xfstests. > > Sure am happy to take a look at that! Also happy if David finds it useful in any > way for this unit tests. I played with a simple selftest that would reuse the existing gup_test infrastructure (adding PIN_LONGTERM_TEST_WRITE), and try reproducing an actual data corruption. So far, I was not able to reproduce any corruption easily without your patches, because d824ec2a1546 ("mm: do not reclaim private data from pinned page") seems to mitigate most of it. So ... before my patches (adding PIN_LONGTERM_TEST_WRITE) I cannot test it from a selftest, with d824ec2a1546 ("mm: do not reclaim private data from pinned page") I cannot reproduce and with your patches long-term pinning just fails. Long story short: I'll most probably not add such a test but instead keep testing that long-term pinning works/fails now as expected, based on the FS type. > > The kernel module interface is a bit sketchy (it takes a user address which it > blindly pins for you) so it's not something that should be run in any unsafe > environment but as long as we are ok with that :) I can submit the PIN_LONGTERM_TEST_WRITE extension, that would allow to test with a stock kernel that has the module compiled in. It won't allow !longterm, though (it would be kind-of hacky to have !longterm controlled by user space, even if it's a GUP test module). Finding an actual reproducer using existing pinning functionality would be preferred. For example, using O_DIRECT (should be possible even before it starts using FOLL_PIN instead of FOLL_GET). That would be highly racy then, but most probably not impossible. Such (racy) tests are not a good fit for selftests. Maybe I'll have a try later to reproduce with O_DIRECT. -- Thanks, David / dhildenb