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 7AB4AC7EE23 for ; Wed, 17 May 2023 06:21:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 021B5900005; Wed, 17 May 2023 02:21:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F16BE900003; Wed, 17 May 2023 02:21:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DDDE4900005; Wed, 17 May 2023 02:21:07 -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 D06F8900003 for ; Wed, 17 May 2023 02:21:07 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 98F86C0431 for ; Wed, 17 May 2023 06:21:07 +0000 (UTC) X-FDA: 80798749374.12.0A10CB2 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by imf20.hostedemail.com (Postfix) with ESMTP id A6F9A1C000F for ; Wed, 17 May 2023 06:21:04 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=P8RRYSTS; spf=pass (imf20.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.49 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=1684304464; 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=s3ZoBkyA20S5DTdyyP5tByv+QSgEyMwfqwV8c9kD140=; b=iUM8LGxmucaDvA0hzT3rWMHt879qtSOOMzLy3W8/rWUIOMmx4lIo5/gVt5wxUhzdWrsJDt Wu0hItUS+I3cRIFtUp46kS6R3iqqTgdMrh4pi6Yi7lKAsQSskFu4X93C8AUDjxsR4OvekV vnKgYMSPwPJNM83M485J2pWKJUlSU0A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684304464; a=rsa-sha256; cv=none; b=GbP6MZPDe5AGK+cJ96GbtopyvCzE+HBNuaVhKX3gfPAChoT5rV+kcZ33Oe5o33pY+yxmJU csnpv+YOPNhfRwPn+U94G0KP5EUcUlk2tsFsb++0fbRrVaWuam3l92S4+XpfI3XddGidtB 0KR+T+n2UhspHXeTalXCtEFU64r1KfI= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=P8RRYSTS; spf=pass (imf20.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.49 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-307c040797bso168470f8f.3 for ; Tue, 16 May 2023 23:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684304463; x=1686896463; 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=s3ZoBkyA20S5DTdyyP5tByv+QSgEyMwfqwV8c9kD140=; b=P8RRYSTStyO/5/f4NJKVG/ZHYLkeB6wgqmu7btxrr1iDGqSIuosSv/k72eOWuTOeIl F7xdz4xLlW1UC4r5Z/syHHyLjEnR9x1A0xJqqpsFqX1LurpTok0el2TCr/d32/l8WnH9 1OcIFDCPzgTpYA04t/WYA95u6kp51qoIzg/6RbxFxS4gwQOfbXLaLaUNVI5fYTmic8D4 DzqiGeK26Wt3/7WZkOnLO5yKB6QYmF5ELWQO2HObuZ2JCG1FqGJ0/MKSJjsOGKf1GcgJ O160RMjH5y0ZybGk7Z7y8ydtdq1G5nwZSsvHljNA9Dkd+7bDP+u5/iXAu75FCLOWfDqb r3Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684304463; x=1686896463; 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=s3ZoBkyA20S5DTdyyP5tByv+QSgEyMwfqwV8c9kD140=; b=hgFiDwbnWlM/3ncfyW9vm4IYFml49myrxdjm6FVLiP2CogaiGwDPHDJkkfURbb26NU d7PXsVzjmrpkTIynK8N3C+izfRht7vDOyikMHarRUQ+xCmKqHe6saKm8uDaEvL5OVe1O PQVfyUB2OIf62KYxCjbr+6+1K3ekccDORR/k9je7YiX+RTX7L5aCqfcKZXiNnjVRsteM rf87CB5Qhu3lR0X2oFFjr2rSwTW2F7Ow6fyaoKFJ4p5S80On++UpcExkg+dwYVh2HVcL efD9JYW3UsRHO7S62PmgF9g1Iodi9dAJs9nxAhWlElSZgJyn/xRGw2NXP/QpzR8GBWcN uDeg== X-Gm-Message-State: AC+VfDxjlgQedQQIA3SKzBO491AFvPndO4f726gHgpC6ZvtEGltdo3aN oIxgqdgbFGvb0HdOY1P7l9Q= X-Google-Smtp-Source: ACHHUZ618y+YEYNwPVMIefe4aIrlbudzEMK7Q3k92kQNoGobewTK+u0fSxZmD1lu5xRSbrgBq/vuIA== X-Received: by 2002:a5d:550c:0:b0:2f6:987f:a0f5 with SMTP id b12-20020a5d550c000000b002f6987fa0f5mr26388667wrv.5.1684304462838; Tue, 16 May 2023 23:21:02 -0700 (PDT) Received: from localhost ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.gmail.com with ESMTPSA id f12-20020adff8cc000000b002fe13ec49fasm1508567wrq.98.2023.05.16.23.21.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 May 2023 23:21:01 -0700 (PDT) Date: Wed, 17 May 2023 07:21:00 +0100 From: Lorenzo Stoakes To: Peter Xu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Mike Rapoport , Mark Rutland , "Liam R . Howlett" , Alexander Viro , Christian Brauner Subject: Re: [PATCH v2] mm: userfaultfd: avoid passing an invalid range to vma_merge() Message-ID: <1f94f0be-a3fa-4539-9278-0e876f693c09@lucifer.local> References: <20abea10-5307-498b-b9df-8f0b2fed1701@lucifer.local> <9739133c-3ee7-4e94-a6a8-783045a50ac6@lucifer.local> <9174fd63-5d32-4b83-bf6b-27f9cb00bd9e@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: A6F9A1C000F X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: 7spabsbreojrsh7mir3xyo8e5rdhbg97 X-HE-Tag: 1684304464-452647 X-HE-Meta: U2FsdGVkX19N568y6MenwZw6P3b1BvWYI6U4/Ml3pN9kErtyG+viTpDjFvlRRTj/cSZ5tBa2aWQORBdL5V+KJlbRt+pghLjJSwTnIvPPfCJ1NKn8jrtyUErHZN99ClICA7mgWYukIu1z8lNFBgEqV6M1FJimBCWGyQztxDQh0CwciwkaBr7bQ2OuGhxDxPeNyRM06Q2EDNuy/EbSFnrb/aWMZK9vewqSmb1O6tWmLsY8PdqvE6vSEKg7ndgSGzrBBnbTXbvabKI5prBaLezECteCmHmeLdbwPuSAcGZx0UeEENwg1Dj6dfmWzJACbaB034OXhNNviIylZzQtH78N9LsAcKPjE0kxCe0uJVVHYozp9LZ0pbcBMOHtaR8/uT2rfI6DWsU8uFxnxudRxZbw10b8ySg91vziVYo/feHBgvg1CWoVX6oMaOxZLhmnxH8g6SZAGMnWSbQVMzhE3bnFds5KmpJOuTdmiHA3feAbdkNLvsPvwRmnSGlhK0ar8ygE5BYeu8qesfogirfM3+ZsgCay8Q32Lndp44e/jv46B+3SU6XN7tBCJQ9v77N2veOy2L4/A3gdJ7+qjjASRKqgc8C8NZ3Jn0ffwL1hCXnelA4vGRPFYVY7a2yvVFjsRjz/tAFuGAonveOldeN2jOt/9he11aPgRGYXHmo/UPElIs4FpVJ9MeYbTSdrRZVrhL8t7Rvj7E55Ha3P7OLhV87Rps1pnXipjjVETHOfK7elYwfxTpsJ2TgUwA0Uc9UY4CM1N+GStJ5PNQngJWyXPpRu7dxUetHn/ZZPBYZT42NHt9RffadVpcjVseN0egdjyJN7M2rZTUIwLPJr/Ad5J48Toi2bY8ck0Bcbe3ffAXrMquebbiIVrH1/pDZmvV2RaGU+fjgY5bOB9jJNWVi83/8W6cvbhm7CkfHwgBt3kLnviLX6Q5uqArfz3rLqAAtR+sxNcLMPpH6KseHJr4f1GXJ eluRo143 ZmFPLpM+ejqS8ruVZimEHWNL2ecYU/UI5DgvP9M4u+4UWbc1L3PrQ4jrldmyv5ad9A2VMo9wDnKzFUgLBzliJqkGUfxTy7ddTtFKphbq800yGZbZlQaxy6nUO2eGbnEG6B23+9G+Y0D+lB74ThplozcUI682HKzHrdlCJR7eoJeq4L+XzAD+kq1aTDBk/SHmi61Mic9Uq/DiibeOfb6FGYikQeUnXbFsHnpYnTRBC81BqGc7BgHqaUHw2J8sTsa7OM0A8if5rJbuiweqNhPHWkYAZ2Dao1zik7vRKYkNXNaSbQoF1JefNGq9r7OYlKPPvgC8e/SvrGBGSxZn2lbNyibdZIv1rj6YfnkhNIzxdH+RC1/HYBYB8YxHSlkt4p3R7u/3ABCqknqQVqIWnwe1vft464Z+6HTxEDX+g0+KjLJlq6MGQpFdXG7Oz8B7daEmwOMac 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 Tue, May 16, 2023 at 06:32:38PM -0400, Peter Xu wrote: > On Tue, May 16, 2023 at 11:15:54PM +0100, Lorenzo Stoakes wrote: > > I'll try to address this in a later series, I don't think there's much use > > in going round in circles on this. If you dislike that series, you're > > welcome to provide negative feedback there, I don't think there's much use > > in discussing further here. > > I'm happy to read it, sorry if any of my wording was intruding, I didn't > mean so. No it's fine, I've perhaps not been clear, but this has all inspired an upcoming change so it's all good :) > > I think there's chance at least on generalizing vma flag change cases, even > though I'm not sure whether vma_merge() needs change. Maybe it can be > another layer on top of it while keeping vma_merge() as is, but I can't tell. > Indeed, will dig in! > > We've seen a regression on invalid input to vma_merge() (explicitly I mean > > triggering a VM_WARN_ON()) and VMA fragmentation you were not aware of > > here, that does not strike me as a great + clear interface. > > Yes, the code needs time to read through, even the interface. I don't > think I fully digested that myself. > > [...] > > > Ah the thanks you get for contributing a regression fix _and_ a repro - a > > nack :) will you at least give me some kind of a tag... or buy me a beer? > > ;) > > I can. :) > > We actually met on the conference, if I'll be able to meet you somewhere > that's what I can do. Yeah was nice to meet! And only being tongue in cheek, I actually at this point do think your suggestion should replace my patch. > > I was probably hashing in the words, sorry about that if so, and thanks for > looking at this issue! I appreciate both your assertion patch and the png > documentation file. > > It's just that I feel irresponsible when we were talking about having vma > not merged correctly but then the discussion tried to end at there saying > it kept so so it's fine. IMHO we should look into that problem or > something could be missing here. Then when I was looking into that > not-merged issue I found that it's not uffd that's special. Sure, we should try to keep all invocations as close as possible if we can. It does seem as you say that uffd got left behind on this. > > > > Before that I'd like to know whether you agree that the new patch 1 (I'll > > > fixup the vma_prev() side effect) could be a better solution than the > > > current one, no matter whether we need a full revert or not. > > > > In principle it looks fine actually (pending Liam's assessment), case 4/5 > > should handle it, but I feel like we need a comment (perhaps only in commit > > msg) to make clear that we are ensuring that the inputs to vma_merge() are > > either clamped to VMAs or case 4/5. > > > > Let's see what Liam thinks, then let me check it locally to give a final > > OK, if I may. > > Sounds perfect here. Thanks a lot. Great! > > -- > Peter Xu >