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 45100C77B7F for ; Sun, 14 May 2023 17:33:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 995DA900003; Sun, 14 May 2023 13:33:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9463B900002; Sun, 14 May 2023 13:33:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E714900003; Sun, 14 May 2023 13:33:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6A66C900002 for ; Sun, 14 May 2023 13:33:24 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 34BDE4125D for ; Sun, 14 May 2023 17:33:24 +0000 (UTC) X-FDA: 80789557128.13.0E4994F Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by imf27.hostedemail.com (Postfix) with ESMTP id 5733540002 for ; Sun, 14 May 2023 17:33:22 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=lQlKcKPg; spf=pass (imf27.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.48 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=1684085602; a=rsa-sha256; cv=none; b=NgLyL1CoQOOW4DvQbIy7gpbBDs7ODB1Jbu9PaR5MZuml88dd2IUt5s4oue5Q6wR7qpzj0k U0tTJdOKf1Qfaf5w4hWY677zvJFAJk902tnweR354uSiyWcpPEcObz2lEemMVtIlqXtM8+ OboBeetYVDIrSi1cSyFuSuNGMAjjsP0= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=lQlKcKPg; spf=pass (imf27.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.128.48 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=1684085602; 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=3oyPTS4otLOfmn6LYBOukn6SNOD9cL2QMwdCto8rE20=; b=W0/O+O33KOLuda8vKb1GdXghPebv+d0+Ixbv6dWvKlePpZTJY5w7gN42KBEoTWnG0+h+K0 zs3r+ZRxUVoMjHSS+RYPJKuNLLiEcwFLs6+VUOMOry4rp3dKDVtsOChg21xI2llILEXQQ5 fL9cN1EEBhkJv8Gw/XZTHSpBPqGwV88= Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-3f42bcf5df1so63237825e9.3 for ; Sun, 14 May 2023 10:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684085601; x=1686677601; 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=3oyPTS4otLOfmn6LYBOukn6SNOD9cL2QMwdCto8rE20=; b=lQlKcKPgMsLJt1PYvRl+VJBA83DYneeWlWGJg1IJdPizzfzTYkVApVfWoN8B+VLA5G iP/3aseJAKUeyqeEZ9fPNo2KGaOeAXdYWwAVDiN2xYqW//TDHyqtjEysFyxEArAElbvH i7TCtYvav2So1Szs8iN5F61bt0tGvWSV17/xOSDZnf8m/ABfvLByeuH5ZShHobckS5Je WtWrXgoY7TD5/Vc4Wy1rA+O97+6H/YW2rH+6rUkydBfVHNDHN7PAtMmu7b4bCiztS3u3 CIJDptbypmBHF8ooTmCH/g/p7x4gwjbtsQQBfUtnYPg8mz4qFnWJPT5uNsEomk/15KA6 aiqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684085601; x=1686677601; 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=3oyPTS4otLOfmn6LYBOukn6SNOD9cL2QMwdCto8rE20=; b=NzZNxTKNYAIEKR8TaS4ifyPBYlaSuCsuimUgFRD9w+/N3kq9SGYLJU+rOgO/jtoUiC vgz0Ht0jsygzQNGzBBvqh5GkzHgH8AdZjcbNL3mwksztskjVVnnntP6eNxuxd9/91m2g EK7jAsAN8snN/SfEjBR9o8lGl8QOj4iGYhPgQKPKIonFY6t1WJLiL4E2vxVcLDEp8qIk DgvzQxPtHKMnco/VlIF2XV5L9lWDC/ETUSh0CyuszZFwKYYNjsnLwQsJPaWtYV8fW0SR D6C5WmsOkhWi8R4RZ1tfyiFuzrdcOh6ZY2G6D2y1MfpyUpM+5IcuStIOM+cSAFIgIGYi NsBA== X-Gm-Message-State: AC+VfDwCMBg1gcqz0hVIFbQvj9zXsO1nEtE0djzCZAVIF36O4z7aimwj aZ7ts4aNeedt6GWnNJrPlS8= X-Google-Smtp-Source: ACHHUZ6gpXe+/3AAYQBH0swh7QCoG2baZCsxWC+fIQZJKQMa6A3tlGi2eF7LVHATng1qrvpgUbn3Qw== X-Received: by 2002:a7b:c8d6:0:b0:3f4:271a:8aaf with SMTP id f22-20020a7bc8d6000000b003f4271a8aafmr14958153wml.38.1684085600479; Sun, 14 May 2023 10:33:20 -0700 (PDT) Received: from localhost ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.gmail.com with ESMTPSA id s7-20020a1cf207000000b003f1733feb3dsm34484227wmc.0.2023.05.14.10.33.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 May 2023 10:33:19 -0700 (PDT) Date: Sun, 14 May 2023 18:33:18 +0100 From: Lorenzo Stoakes To: Mike Rapoport Cc: Mark Rutland , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , "Liam R . Howlett" , Vlastimil Babka , Peter Xu Subject: Re: [PATCH] mm/mmap/vma_merge: always check invariants Message-ID: <67f638d9-4853-49ed-b2e6-5000e1cea558@lucifer.local> References: <20230511180841.GE4135@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230511180841.GE4135@kernel.org> X-Rspam-User: X-Stat-Signature: giasgk641qkndade3bennd5as7ogdtrb X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 5733540002 X-HE-Tag: 1684085602-754734 X-HE-Meta: U2FsdGVkX1/NLd4SHSoAQ0Ch4YFn2Bu84K+Q6mplmBtdZvFxLdMwCJf4UYFbU9ViYwtkSUWshxj656sPLIZlPQ+Cet7Wpvppbv7PUg2j7vyFGfdStIS3QcZ2JdkhGbyX0gs0cAFf+VYipq/Rpeaqnt/9TZPWWNmq8UPxSdwWYlLLc+sfpsjXq4uThmKj+Lyl3+daNQwq/y2k5u5wLcei4ifI1VLGvv4GLJ45IrwohNoBAvKeBbTBfD7WWVcYpHL2j0u5rx+9TDRu+8F+d6rU1gveUu6hNeYCp7UuCPp9p0FZicbpmC+HHPDQgonA7uiD49coD+0hyG60jjkJxfOnUlTDvsPF0SC7YS6VB9Ab3op+ThtpS37dfzoNSwBtun13TtR31OQpWIpIg6O81R6cAatqikKAQ34gUgPzOtKRgkGkEjQaPHb0K4oTrD5FrWycT6E4pPU3zC9Wu7u4iwSm4io2oYaleN9AawVLP7bcVGxbb1ttlckCcMnrxAVxPZitel8jG9xniNe2NMkO3sWLgXedTANBts2DReaoodipQS/gq7CNgAWjKOJU0NV3fNeL5Aq6NryuYE0IwMfGQaZOkzyj1a63hStAxd7t2udhKAnBqFY19+VcCJyD90NdEu/qsHfbjqBohG5sARQe5G8XNPuK5dGYDr7mI3jU0sVeB8+uIlafTSFcBzW6FOiTDp1rj5Z4xrmlTJRBaK+dKC9Ew/2VW73aQ/JJYtgwHY2s03O6OcaQ+jU2Bl9wZ/v8Wh6BntL88MnjQzvx9fdndLxs1gh7zDAEV2Yh9fvDX/D8mQLXDs7gLpYK5KkDoCWgprcaQZjQ+0cJxbox39WpuIQCwIuds5Wc1qvtui6IjH3r3X+al6gSur8uJNr2SmzEiTxygI+x7K4bT9RDBtN3OKy0R+TtX08/Oq/4u+wNC5fhbmLTjs3BCpKmfjhPK4Pm4OsJmfjLfVOZHEnteNz3xs9 A/YnJyl/ IPzq9hQO0+5ocBytqUB7xSmhCjpH0RQe/9ASd7dUGj0kbCF+DNxXhBpTkHNHB9dnXQ62PMHHSK12PzeHe1kglxqP5b2oUapPNYHKBhUN6Kuub+fV1B/jL6BJU2tEMN8Uwa1EpxsOP/9l3+O4/Ez+2drLyc3GGe1HEZyT8lT8hcKFKGvcUNOCJJWIWN/wiCDW1Yt2XsNWliKkUNjPmIJvrVowGs8UTKfP8KhyCZqr0NneGq0Y0EhDYjMkn+HG4pLaDZ7eqQHRJc45mmUkh1qCT9mRs8tqe1Y7QS2syZIDfOJTsYwTwLKs/w8xgK2bc7nfpPDc4hgI7iqhls4mf26sVF9WICgUylcNz/dnr2DX55O//kjFceCkyzI630OiIIOYfh6f4yUC3Cj+gYpqVWlDJ3V/aV5TcwoqKusG8C6zknUKNMJt1uNKuQwC4hwTZIrVUpz5NLuRTGEwiNNVrK64ekR2myx2lkFZmWXqWZ0A4acDv3fFiQHw38WabBw6Sap4Tzr8pNMD/1sh5rF+U1+pCd1+74Q== 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 Thu, May 11, 2023 at 11:08:41AM -0700, Mike Rapoport wrote: > (adding Peter) > > On Wed, May 10, 2023 at 09:26:10AM -0700, Lorenzo Stoakes wrote: > > On Wed, May 10, 2023 at 05:17:49PM +0100, Mark Rutland wrote: > > > On Wed, May 10, 2023 at 09:04:44AM -0700, Lorenzo Stoakes wrote: > > > > On Wed, May 10, 2023 at 03:15:51PM +0100, Mark Rutland wrote: > > > > > Hi, > > > > > > > > > > On Sun, Apr 30, 2023 at 09:19:17PM +0100, Lorenzo Stoakes wrote: > > > > > > We may still have inconsistent input parameters even if we choose not to > > > > > > merge and the vma_merge() invariant checks are useful for checking this > > > > > > with no production runtime cost (these are only relevant when > > > > > > CONFIG_DEBUG_VM is specified). > > > > > > > > > > > > Therefore, perform these checks regardless of whether we merge. > > > > > > > > > > > > This is relevant, as a recent issue (addressed in commit "mm/mempolicy: > > > > > > Correctly update prev when policy is equal on mbind") in the mbind logic > > > > > > was only picked up in the 6.2.y stable branch where these assertions are > > > > > > performed prior to determining mergeability. > > > > > > > > > > > > Had this remained the same in mainline this issue may have been picked up > > > > > > faster, so moving forward let's always check them. > > > > > > > > > > > > Signed-off-by: Lorenzo Stoakes > > > > > > --- > > > > > > mm/mmap.c | 10 +++++----- > > > > > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > > > > > > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > > > > > index 5522130ae606..13678edaa22c 100644 > > > > > > --- a/mm/mmap.c > > > > > > +++ b/mm/mmap.c > > > > > > @@ -960,17 +960,17 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, > > > > > > merge_next = true; > > > > > > } > > > > > > > > > > > > + /* Verify some invariant that must be enforced by the caller. */ > > > > > > + VM_WARN_ON(prev && addr <= prev->vm_start); > > > > > > + VM_WARN_ON(curr && (addr != curr->vm_start || end > curr->vm_end)); > > > > > > + VM_WARN_ON(addr >= end); > > > > > > + > > > > > > > > > > I'm seeing this fire a lot when fuzzing v6.4-rc1 on arm64 using Syzkaller. > > > > > > > > > > > > > Thanks, from the line I suspect addr != curr->vm_start, but need to look > > > > into the repro, at lsf/mm so a bit time lagged :) > > > > > > No problem; FWIW I can confirm your theory, the reproducer is causing: > > > > > > addr > curr->vm_start > > > > > > ... confirmed the the following hack, log below. > > > > Awesome thanks for that! Just been firing up qemu to do this. > > > > Cases 5-8 should really have addr == curr->vm_start, I wonder if it's > > another case but curr is being set incorrectly, it should in theory not be > > the case. > > AFAIU, it's a case of "adjust vma, but don't merge, because prev is not > compatible". Looks like uffd first attempts to merge compatible the newly > registered range with adjacent vmas relying on that there won't be no merge > when addr != curr->vm_start and only after the merge attempt it splits the > edges. > > I think that moving the split in fs/userfaultfd.c:1495 (as of v6.4-rc1) > before vma_merge() will be the right fix. > Indeed it was, patch at https://lore.kernel.org/all/20230514172731.134188-1-lstoakes@gmail.com/ [snip]