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 169D9CD484A for ; Fri, 22 Sep 2023 18:03:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0C966B0306; Fri, 22 Sep 2023 14:03:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9BC736B0307; Fri, 22 Sep 2023 14:03:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 883DD6B0308; Fri, 22 Sep 2023 14:03:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7432A6B0306 for ; Fri, 22 Sep 2023 14:03:37 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3FC598114C for ; Fri, 22 Sep 2023 18:03:37 +0000 (UTC) X-FDA: 81265006074.02.484FEF7 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf11.hostedemail.com (Postfix) with ESMTP id 4B56B40003 for ; Fri, 22 Sep 2023 18:03:35 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=DaJy7MpL; spf=pass (imf11.hostedemail.com: domain of jannh@google.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695405815; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=YWRcfEirLBnqu+2f/i0ziGPl2c2yxMbMUA4Eo0VdaLY=; b=6YcMN29axcI2X5vkWgtXJhrnqwK0SjTP+nNloewiIZINwg3nZoD3VvvMnQQf8ANYObNvWt 3bEIFsojt8GCDWVRbhvMVrrWuUBjCfAfntcwAWqYJepyKTQL9QAhs5BuzCCOXCOzkIh2yi 1MVauCozAtVQ3N4REY0IdijvcOLll1M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695405815; a=rsa-sha256; cv=none; b=vst9eXSXfJ30SOwbqeNCbtxSTMsQKUpOiDxL+tKeckFKaCfjcUZ3RtMr9aWE/dUbzYYP4U 3Ex47w7HCM/QbbJ/qHjNKGE2J89eeHcUjx7ZK+YWjdK5IUQwHypiZykldeWdvaheWRF5S7 bs/pL5hB6j6Gsl4bz9GE6WcddWf5PxU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=DaJy7MpL; spf=pass (imf11.hostedemail.com: domain of jannh@google.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1c4084803f1so16835ad.0 for ; Fri, 22 Sep 2023 11:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695405814; x=1696010614; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YWRcfEirLBnqu+2f/i0ziGPl2c2yxMbMUA4Eo0VdaLY=; b=DaJy7MpLdi3aaUm4O+slfmB1zd33MQIVySVbVt8Ik4qo2ZHiMy5NvtwIsoqb7toaUF RfWEK8AgphwV1vfEQm/bo1UsV8zkDELzGPDNLCddjFYYRialQ0QmW4goy2RMMHCLr4lC w75A5KlFiwAKC4YXJcQJB7kqnTYnBFL9kQc1RbtM8UavyhEjl0gSxTB+4ew40CRV1HtR sO4MO5iFVmpt8fY6q9XcmOijnohGkgLK9uUPUOatrlqv1hax+kw8zFW2MdwiIcTXoyjb GyBPNQp4lz2iffMO0z73EQjIefpBlEsbF7hJbpYOPWQ3puP3+uLpYRI2roVDC8E88Cun +DTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695405814; x=1696010614; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YWRcfEirLBnqu+2f/i0ziGPl2c2yxMbMUA4Eo0VdaLY=; b=oA40jWQVvhabeK5/xIoVelKykxFQ8ngJtx8sajUiFFThBhySEJPUnYGvBaviDZIDLK V+QStu9s2I9l65zI5bmC37jUyAatl/MCmeLf3VR9i/okDfQt95+brLTv48DDkim9rZBX zu93zbbKI4Gf3ODKdgdaFrBk/6phiyvp3WqXfXNbs/GdjoAS3FgJXWJ+wH67d76JLBuf yd6e6qeiuX+auM7zXOv8mahkUoiFS9KR5xdx81Oy9ovH8K+CaU4eekGuFg2QpWAYxTaH fvQqS4/h98Cp/tH0q0cJsQR65J1bGXe9V7luI4209hqWPIYsG+/FuY3l4j7ZTD4HKWNF YGgg== X-Gm-Message-State: AOJu0Yxija0mCQ8fNEhbXkQAanPIBHRt5OeMFh1fMVK+EJLNXI0h+0RK 1EZYlb40gItTzQ7Ae0VopxoHu444m/XCsCFM9y+lgQ== X-Google-Smtp-Source: AGHT+IGA4lV407J2PNGlN1Ck3nndl90O79nsg9m6IlHFRJrs++uTkePr3y78Cx6b+cPt4B3AL2UbI9K5VvDmHx7i/kc= X-Received: by 2002:a17:902:da8e:b0:1c3:39f8:3e72 with SMTP id j14-20020a170902da8e00b001c339f83e72mr25102plx.22.1695405813820; Fri, 22 Sep 2023 11:03:33 -0700 (PDT) MIME-Version: 1.0 References: <20230816161758.avedpxvqpwngzmut@revolver> <20230816191851.wo2xhthmfq7uzoc3@revolver> <20230922161919.6ct5c7tj35r4ex7m@revolver> <20230922175232.gneuhwhzs4moql5u@revolver> In-Reply-To: <20230922175232.gneuhwhzs4moql5u@revolver> From: Jann Horn Date: Fri, 22 Sep 2023 20:02:57 +0200 Message-ID: Subject: Re: maple tree change made it possible for VMA iteration to see same VMA twice due to late vma_merge() failure To: "Liam R. Howlett" , Jann Horn , Andrew Morton , kernel list , Linux-MM , Lorenzo Stoakes , Vlastimil Babka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4B56B40003 X-Rspam-User: X-Stat-Signature: bh71irpd87f6p3np1ajmpb1c4398bf6g X-Rspamd-Server: rspam03 X-HE-Tag: 1695405815-326305 X-HE-Meta: U2FsdGVkX1/HMBVSEQPLlJpYytHrxfi4d8sZCDPb0Gi++toSNfSd09pwOn6G3LxBhH2ulMOtud0KFCxMVPO3GF1NTnDMakXTblXGhmXyIxP5Gqf6B+DFzzSN81ypQ401zBEi+ZJz9pVtN7n8R+oZevMzJ7xFmMf4gDhFs8849DH3BFyi1g8zqrqHwTfI86+ADujJOorG+uchYA0HI1pUNvOTEI71zbsj07AmZUQHwd26pLWAtMtvN+mwdRWhPStUpBA4jDT9WdVGM4qrE/oQgPEJKIUKwLfczpZmKUBm1hSBGoapPgQHYlmNZyj92H+9E2Ir+ac5Avur6dOuC/NGvD4vg+zFNribk+SgjtFe5cQgx7buHCSvybW7y5q+YdzNAtioZFSfV3qog6IXegaotJR4EcTPmChCu9YdB8J3DbJBI4lKLpC+/AOIIIQdyZeXG7hXu6cCjEWmk7JIUjxVUHhdCQtEPTTvphLvuRIrNhcESVu42DyYPcwRRy2qpPYEVackIBj6nes3ohiawK9ZC+TZmMZnoudm9STOgwggEImdcljwOHfmUL6FHlpHtlPnnzylUE3OfB+r/NbQarB4PG2OuklgFK6LV5b+Qb8zEz0rzZ6oxkZdn1jWoOkZhBSNQbvNqFXrBL/o33MbBqkXLTrl4KI//pShYcua9l4YavULjs6teZiesKFH4WHt5k64y+hmNiHMf76x/v6/GGg/WXF8blrlPR/FjR3cUcCezghfP7xxUQMSe8GE9cg5ZB1o32KSK7c5jAVUKr8Y+wJX7EH4IgyVMcGHDEbE4uTquXARRctdJ9hqon8ZexXc+h0MscVys5c/1hMMBbyx65qhOe1SrT3DRJJSmX1HELT0wov/CbwJYYaR8yHjV4kYirP8AKZjz+4E3Sd5j5IEcV04V17sc4K39PtituWHJF1Meq9MgRNGdSm+wpAzBtGoij/yciA9ocqPu9W+Bkwl4AV 61jtB4pa DoqicjrJqomGKrT6xLIWHNPAKhm4/PySFEAN9P2bWGEOrehAWIcyAzwSLk2rQ0NUt+5I8Deyd8SqnsZgBLH7PJ+XT6B30MSZxxD68HrXg7LDIwJx65CGXLHVLQ7uWLn7RW/F+RJc/9/mLum9798hg1Jp6T4pZ6IgLse+B81vzv6jwzcQJfx/zPANQ6xtjRWfGIrn6aox3IK0/OJkO9yAL3e75xQGpKzW/iMUzxtYQdGwaP3JPU+d8huZgQ7Bi+VsDcrsdDC+YsxjIBLcNfzefaUIcmQ9IFfpAU0LM5PwSJyOy3XJuFN8umS4/J4ZfMxViq1lKXZFwxpazbHFlvLP+xZA11j1R54O0rnHAGT491ajL4T0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001029, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Sep 22, 2023 at 7:52=E2=80=AFPM Liam R. Howlett wrote: > > ... > > > > Looking at this, I think it's best to make a label and undo the > > vma_prev() with a vma_next() - at least for now. > > > > I'm also reading this for the error path on dup_anon_vma() failure, and > > it appears to also have an issue which I'd like to point out here befor= e > > I send the fix for the first issue. > > > > ----------- > > vma_start_write(next); > > remove =3D next; /* case 1 */ > > vma_end =3D next->vm_end; > > err =3D dup_anon_vma(prev, next); > > if (curr) { /* case 6 */ > > vma_start_write(curr); > > remove =3D curr; > > remove2 =3D next; > > if (!next->anon_vma) > > err =3D dup_anon_vma(prev, curr); > > ----------- > > > > Since dup_anon_vma() can fail, I think here in case 6 we could overwrit= e > > the failure. > > > > That is, we will fail to clone the anon vma and mask the failure if we > > are running case 6 with an anon in next. Once the first dup_anon_vma() > > returns error, the next call to clone curr vma may return 0 if there is > > no anon vma (this, I think _must_ be the case). Then we are in a > > situation where we will be removing next and expanding prev over curr > > and next, but have not dup'ed the anon vma from next. > > > > I think I am incorrect in the error being overwritten because we won't > call dup_anon_vma(prev, curr) if the source of the previous call (next) > has an anon vma. Hm, yeah. It looks pretty dodgy and I guess it could use a comment, but as you said, it seems to actually not be a problem... We could do "err |=3D dup_anon_vma(...)" there for clarity instead, as long as the only thing we care about is whether we have a nonzero error...