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 05960EB64D7 for ; Wed, 28 Jun 2023 19:51:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5D9D28D0002; Wed, 28 Jun 2023 15:51:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 58A428D0001; Wed, 28 Jun 2023 15:51:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 451FE8D0002; Wed, 28 Jun 2023 15:51:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 36E8E8D0001 for ; Wed, 28 Jun 2023 15:51:04 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0A54F12026E for ; Wed, 28 Jun 2023 19:51:04 +0000 (UTC) X-FDA: 80953200048.23.837C8B0 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by imf18.hostedemail.com (Postfix) with ESMTP id 15EF61C0003 for ; Wed, 28 Jun 2023 19:51:01 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=aI19TtPB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.46 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687981862; 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=XagGNUSMlZ2YxfStu7vBidTnF8doQVt9/OwIdHD5PeU=; b=tnniqVIZAp7HHaWArhV3wdVGA3qC77x/VVOP0SgnF56vu3DeQ2uuGLGPqE1dkN911CxLDP 6mAa+Vh7G4ISVBNsun2zYA1j4Kx36bdWSkf3F4mvfsvLnRjDuo84z186XuLy6Qzfxv3CL2 632y59oSZPGaQVchxe8deB8izS514/A= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=aI19TtPB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.46 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687981862; a=rsa-sha256; cv=none; b=nqgKliFAztRjQbecoxR0wZDeoz6A4deDK1P6t3nC398vvsxfntWWxKxDEtgJKHBjWK4SZS gUr9gsia+WjgqbfMZKuohmfZdeNGhzaZ0r2IQIG2JprqxM9Eml4kkg5oa3xZdIuk3hokZi WXkYgT/ELsd5t36fgiu9AJ3NXmYJ+fA= Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-313e742a787so311387f8f.1 for ; Wed, 28 Jun 2023 12:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687981860; x=1690573860; 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=XagGNUSMlZ2YxfStu7vBidTnF8doQVt9/OwIdHD5PeU=; b=aI19TtPB0HZxkWtcmWaWHVpCLB2ui/jaTO3L9MOtOyVG6Qhk0SzhtPqrxD9beEfE9Q AJmZou1t7QgXMX9u4ZxwxXvVmqf6DTmJt1RHqw9tdJGJ0BiPRzGgV1/jmPAHRiqJlZAO rM/kT8pWmG2Okog9HqI1CYcjIjlT/M+q37PCQZe9rz8xYiJFZXAJJHBhEmwQclksggCX 2T/DJ6Y8UANk3pplycwDea+IddP34eCtjLKGW3kyB4tURv8xyWQLFygi3tK/td7AYHoc 4bLsqDKBLVrf6zxsNUTCqm/GOK2pKUgfmX0/SF2IHNZsq2optTA7QjeMvoWJVMXjSp0j 0SoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687981860; x=1690573860; 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=XagGNUSMlZ2YxfStu7vBidTnF8doQVt9/OwIdHD5PeU=; b=Xeiwfdeu66kul5MY3OGhj9ZFoAiMGRbXXZI73VW9Gp/wqzzT3xRLoSrX+9k3hpnYNu E7E2DSScuz79GNdAhE1I8OoH5JfCFG7DSA/l3eknSeGJ03W66Yu82ly/xXNoKEcAb13W 1os/FBdYZGWALlPSuIKvGkF294BX/kbxAH4edmWH/Pb90lKXxzF+Dnjs8U1um0QPuyyB sqmq2sm5bWGMAYzgf6sc2OAVxjmyO0+k7YKXC69OSveIjg0KHlysDRzFKfcbOFYqoqcV QTGjvXe0OcLXH3FyM26MgVLEU5ktMB44ZAK1gBpO6Dzu/XNdLmg2oprnUl1W2t+idqmf T68g== X-Gm-Message-State: AC+VfDwwfSMO8C7ZlRFzDwZZiItGA4MJWRjhejupJ5ueW4Wa1qB1Tavw byatjkS0LVA17kN4+G+KBDY= X-Google-Smtp-Source: ACHHUZ4DkdsPnRN96+9fvZ1oe5acppJA1dzDhm0/IZ4Fuc3oQjqtcRtv+UM0Wd74boHlX13ESVfnmQ== X-Received: by 2002:a5d:49c1:0:b0:314:c16:56a2 with SMTP id t1-20020a5d49c1000000b003140c1656a2mr2592622wrs.14.1687981860200; Wed, 28 Jun 2023 12:51:00 -0700 (PDT) Received: from localhost ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.gmail.com with ESMTPSA id s2-20020adff802000000b00313de682eb3sm14057138wrp.65.2023.06.28.12.50.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jun 2023 12:50:59 -0700 (PDT) Date: Wed, 28 Jun 2023 20:50:58 +0100 From: Lorenzo Stoakes To: Linus Torvalds Cc: Andrew Morton , linux-mm@kvack.org, mm-commits@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [GIT PULL] MM updates for 6.5-rc1 Message-ID: <986f48a6-5ec2-4f69-b1dc-72fe5b7ada77@lucifer.local> References: <20230626085035.e66992e96b4c6d37dad54bd9@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 15EF61C0003 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: cias4wf35qnbmhcda7h6br1ckxo7ix1k X-HE-Tag: 1687981861-976402 X-HE-Meta: U2FsdGVkX19yRQVBataNEZQVIAXERud6oitL22UQAbzdimoYxU4aOOI2rBOlUGWkhbvhFusuB0lxz8SkmZFBEyt/pJ3M9LJboH5E/sjRS2PTvh7xGT7PdeqCLRklals4CVSeap5RT1cZMOOXtiGmmyg1MLu8Z5e33OMxMT+cW0KpJn8eeMEEPZrJj7/jW16UhfXC/QCoQPGxl0rJGMB/Aaff6dMIp/6AXZkZncbIiLG9q/V6F3vvfRUhYgu4dRlrUvrb7QwgC/Lg9DXT1vvX5YLWpQIzsQtrkE+gb6IYBahbRLxu16413pghbr0NliLDktWrziiPFW3IqPSM5FU5ihIJjqHefcf9hJ85UHYh37sd3YiIm5IZucVyQs1rG4yWzinNZXapiMrLNbyJJ/RzYuHe7IS5cqrb/ZXJZhAdaaQEjGv91Cwuj0NyuFEQqf8qsVvLsBJaCqJnKdQQd1O4zI1LW3dlfEcxsJonrPtKfSgnvVN+0o8Kq6f6KY0ddtuy7Wmu8yMaBUNas27sd4DJiPr1dPMjFWf+I4snPJsL4Ejvikx5IxnPTxOJoVme8Ef4RiiNgLigp5nZxF5bD9jzlGPBG23kx7Hq612q1WGmmvkQmNUPvPOUoHaVPvgmsI3X1aegIw80bjnrebFw7olqR/MoxTmQs4zGYjQSVmvmBhStREyJ+SVFxDxVODSFiA5xHbsc6J8fl/gl3zf5Wsu2iherUHJP50DtcVt1qNhHGWxrolwW9oJrGiSz0t+swzWcZUFgTF44qp76L3fr4s4/cLbtG6F6hszePX+XPoy3feL1sy/11BZSYHb70uqmJryDxJ+ZA05j/g7Hr7ct9SlIDqhDwKu+Y8pLVBs1fBMricjvF5H0uKx1fWq+loaU21I6Zij2OhntgKNBmmk4jnJLH+ToMxnBTbPdQpLsU2j8MptZu8x4nsYIgcnewb0IZebk8lysbKo3K20CtluhG5e qNPH/0Pl XiivnmRFD9+M847GdlVToqn2Ybcody5exluTwNqvljZ7UheFU4Rt1Nfx1qbop89xdvFuGrgLLF7RK4sCKXt8/xLAp/yonTL3HZ3hREOb5CsYFh9GzR72GpBXF+mrDN8YY6CYZZr2Gmsfddv567wk4H7s/fU72CjgpjK/LbhGbNXQ+CKQHqUT4dzIzetVxs4F1i2d6jMPhIDose18FVEclThPd6dKumVXg/TgwLFySVOV0Kaempp3bu0EzmaKIGuJ2ptqlxCa/dO+8H0Hak22SVkXEmFum5crRCekl8xx53JICiVbYmlVL0U6qFWXHagcTcnWhanJUxhWwl3bmBlUioRFqcBAzy1lJ+W1pyJ361cxSbiHDL/fYmscTgvYZHAKDu0m7H8lpcqVp+HMr5/0nBAV9IQSWZBMItFc2FCZHE6ZUtFMMOGjxC5aynq4YDmXZZCu20KQlIIHkKlE= 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 Wed, Jun 28, 2023 at 12:19:42PM -0700, Linus Torvalds wrote: > On Mon, 26 Jun 2023 at 08:50, Andrew Morton wrote: > > > > Linus, please merge the MM updates for the 6.5-rc cycle. > > Hmm. I have merged this, as pr-tracker-bot already noticed, but I > found a bug after merging it. > > mm/memory.c: __access_remote_vm() is entirely broken for the > HAVE_IOREMAP_PROT case (ie all normal architectures), because it does > (skipping the non-HAVE_IOREMAP_PROT case): > > struct vm_area_struct *vma = NULL; > struct page *page = get_user_page_vma_remote(mm, addr, > gup_flags, &vma); > > if (IS_ERR_OR_NULL(page)) { > [ ... ] > if (!vma) > break; > if (vma->vm_ops && vma->vm_ops->access) > res = vma->vm_ops->access(vma, addr, buf, ... > > but get_user_page_vma_remote() doesn't even set vma if it fails! > > So that "if (!vma)" case will always trigger, and the whole ->access() > thing is never done. Ugh yeah... This came about because the helper function handles the vma_lookup() case but obviously we now only bother with the vma_lookup() if the gup_remote() succeeds. It's made a little trickier by the fact we warn on !vma if the gup succeeded, so probably special casing this one makes sense for now. There's been discussion about eliminating this weirdo thing gup returning 0 but being treated as a not-failure, I will probably try to patch this soon for the one usecase where it matters (uprobes) and maybe also look at this whole odd 'special mappings are ok in this one place' thing here. > > So that __access_remote_vm() conversion in commit ca5e863233e8 > ("mm/gup: remove vmas parameter from get_user_pages_remote()") is > entirely broken. > > Now, I don't disagree with removing the vmas parameter. I just > disagree with the get_user_page_vma_remote() helper use here. > > I think the minimal fix is to just put the vma_lookup() back in the error case: > > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -5592,6 +5592,7 @@ int __access_remote_vm(struct mm_struct *mm, > * Check if this is a VM_IO | VM_PFNMAP VMA, which > * we can access using slightly different code. > */ > + vma = vma_lookup(mm, addr); > if (!vma) > break; > if (vma->vm_ops && vma->vm_ops->access) > > and I'll commit that fix for now. Anybody who disagrees, please holler. > > Linus Yeah I think this is the best fix in this case, we're not doing any additional work since this wouldn't have run in the helper.