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 E13CAEB64DA for ; Tue, 13 Jun 2023 21:29:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 37F908E0003; Tue, 13 Jun 2023 17:29:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 308838E0002; Tue, 13 Jun 2023 17:29:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 182198E0003; Tue, 13 Jun 2023 17:29:29 -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 05D4B8E0002 for ; Tue, 13 Jun 2023 17:29:29 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C86CE1A0631 for ; Tue, 13 Jun 2023 21:29:28 +0000 (UTC) X-FDA: 80899016016.25.F1B5C80 Received: from mail-oo1-f45.google.com (mail-oo1-f45.google.com [209.85.161.45]) by imf27.hostedemail.com (Postfix) with ESMTP id E1C2740005 for ; Tue, 13 Jun 2023 21:29:26 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=UvQvJ1HK; spf=pass (imf27.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.45 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686691767; 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=m5HE/be1fUs4mLPz2SaYKZccHzMwcgmBbh761wXiNnM=; b=Dauiwge9UvO8KlusAQKR5y869KfJcQpoVtYnVNLSFXGFpG5h6QUSclaTDj4OEJx2Gexy09 utXSDPPdbvB4ZLSJW4ZWk8eCMP2euYF+YPZgid1fkBJ7rEs10gzTqctRPrtvw961j9jYvf f/NpkbvzciX8u5EuuHe9jsirEprAVZE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686691767; a=rsa-sha256; cv=none; b=nDZaudkn69x1WKngOuXCeEsYkC4fRLKWdVoHkLlpAtmP8zIq4ktgrtBDj51BAr2b/GfEyG Lt1ajGSAbd1OvAqoE2MtAm/kU3KjrHhaD6q0SLn8ZelTySByuuEK1gAbjbGCjKjJCgaFi0 S8y4KrdfNMP/LkMIB/DSqLfpAz+ahkQ= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=UvQvJ1HK; spf=pass (imf27.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.161.45 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-oo1-f45.google.com with SMTP id 006d021491bc7-55b78f40301so24011eaf.0 for ; Tue, 13 Jun 2023 14:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1686691766; x=1689283766; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=m5HE/be1fUs4mLPz2SaYKZccHzMwcgmBbh761wXiNnM=; b=UvQvJ1HKFaAQUKjPmhDlN7jMvGSXBDIpN8pkmYF/Bwah+h8t3CYvGVpSGid2I0e1od EVrSYsLxjZIKskXU0Vvt3brC/t3bA5LGP8JPpEtjL0RMSbnCD3G31q5hwxWjam+kQ7ex xxV7ezNLLsVB0tD6+MpVreQkIk6yJG7zTek10= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686691766; x=1689283766; h=content-transfer-encoding:cc: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=m5HE/be1fUs4mLPz2SaYKZccHzMwcgmBbh761wXiNnM=; b=bOcL0LZw4mOYabOZoW0ySu0ZeLjQ9pAEkiofhAN9H21I7nhpCZVwuFXDPv0vFkk1nl Hchy1V1uKAav5hrMqSTmmD9i4truz6IUF+VCMHDah045eFERo25MjXmF62JF8tlI5Vzy ty6z9ijn4ZAxG51QhKKjj38SSsdPRaxK6IZekqwcdR31X193FBZ/Q/5spsqUHWf1AQ2i r2P5AU28b6vGmUVcxret+g4T7cg9dewdAMFbJAGVPM51MJBlavagP3hlDFjMGIhB3Soi uSL65TrKb6BckS1c4fhUmPtCvb8Sy79+Rc12mAXmfCUHVpZk7r4wEH8XgLr2WD9x8Pwy +thw== X-Gm-Message-State: AC+VfDxhHWoqFKHit6XfxKPt2kALqR2pUqfM7OawdfotcZY4LqLaZXAY XgkX7Pnn5I1F0RQGb7iBQ6Ate5Shu2i3A89AC9B8sA== X-Google-Smtp-Source: ACHHUZ7fbo8Kxz8Uov9OlVFEvorMOAwEZuA89XR8G2tpT+1NdcpRdHiv7waH1TAy4137LEZTgCftvDdUkcR4RpaqMKg= X-Received: by 2002:a4a:e9e2:0:b0:558:b424:8c31 with SMTP id w2-20020a4ae9e2000000b00558b4248c31mr8037821ooc.0.1686691766049; Tue, 13 Jun 2023 14:29:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeff Xu Date: Tue, 13 Jun 2023 14:29:14 -0700 Message-ID: Subject: Re: inconsistence in mprotect_fixup mlock_fixup madvise_update_vma To: Peter Xu Cc: linux-mm@kvack.org, linux-hardening@vger.kernel.org, Liam.Howlett@oracle.com, zhangpeng.00@bytedance.com, akpm@linux-foundation.org, koct9i@gmail.com, david@redhat.com, ak@linux.intel.com, hughd@google.com, emunson@akamai.com, rppt@linux.ibm.com, aarcange@redhat.com, linux-kernel@vger.kernel.org, Lorenzo Stoakes Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E1C2740005 X-Rspam-User: X-Stat-Signature: 8wzgkdhs4uju76j3d3kh7cor9myyga8t X-Rspamd-Server: rspam03 X-HE-Tag: 1686691766-574537 X-HE-Meta: U2FsdGVkX1/8fKBjfP4NAKvkpfLs2j/KLgIXEPjKvtqvMCsmfy48/GXsRJScZ2qS8inwyjn9FrP9IFiAvUTiCy63ZOcLW5yZ7chi2nqUUplVKWigqxzOoVHvFnRd7wVVDD94KblvNZcLiPMwOs9AbYBAD1+yRq+XT2GkVsJ22zUKQgenqHoI8P90mx5qPo3aR4vi44inE84D0+IOQkJ2GJ62xfu55bYkq1Ox8sijLbfIyRd2HCJKib+erxPNUSADSpsL6ZdiyBig+gt2Og9ju7knOcCq/3bPRibUO9U1ZbpY9qrxiSzT9ZBSxqrrwQcYfYRijOs8lo6Z5R/WwZvoc0i01G1eLcSyVZcr/xvNeubIp05NhYY88vrHw19vhVtG8Cw8M0cu9sdYrXfnwbKDkf7fDQgmEb2qhsz6QchMXSIQZTAydP1VwwpxPoaISkrQPl+xDZ+p10HqJSRvi8YtO/fYYQ804G/fv42mRl4xNr4yjRIuliKALZ1YczfYqtHyXAmMDx7psldPlDO4m5jQXOhwR5z2VGGYk8c/C5vuAE+B69+wJlTYa8pUCHPiGWjk+HhtBFg4nkkHiGMjOv1UFl8OuY3MRxfbN0yQeqLHygvCjuxsyzCaL7FLj4yqELev6+axxQ4ksdDlq1PNm7OHVh/+T8+DVB2jagiVXfyej73WBgjrP8wHola1dkaAkvnwR5q6Mw+m78kKxXaXagG2WW48cm2+NXIpt5rq6HYf3yWVcvEiN65vznIEaBuirCm9A6pt57U0RgrAAj63NP8pPt0a464dM8HNSWh+l6hECIDgTQcf6e/2ZCWQsAPhgxvAxNMk/t5iSrIWpULimBjmVbRMX7NHMPl5eYLclq+SHjuVZQdvZec5WCvXt6oWpmZY0xhlIoO6clb/uZtAfwnfiM9SCP7zMKkQqpTT7uQAfcCcXn28IT9Bzwb7U+zsxV8CZ9Vc/FzRCJKeynwZEj6 TAjs8fc4 30UIId8+czU6mAixZvGsevpILsf2r6FzZWiU4UeQ8I8NZtj7YUmI6EoCfJEHgRsYNTbKol6izkTUl2gTcwU44fD+iXg4sylAKW79Sf+SnAxAlG3Jxd311WNopsMIrilXoiXwXQVnf+HJf8sbblJ/3nHpvZD9Uw2G+cMh4PfYqgMVdOCSvKfvYXvzdG9rnBwDdFSHkUjZFEbSqtEGYux9sptWhutQ9LJp5Mb3L/6BtJ013J/ivm664lCm129iu+9UftOA6kgYZGO20gZnfW0O/VGl72K3RtbM3M8Q8zS4NhdrPu9E0qDaVNqD4O1kdZuyqC5WUT7GhNxhcwmdbUmJxMuWdDG9Wgua+4EfzSN+Tfn7AdR6DgwpVSqVt8fB0rbxvg3RA X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello Peter, Thanks for responding. On Tue, Jun 13, 2023 at 1:16=E2=80=AFPM Peter Xu wrote: > > Hi, Jeff, > > On Tue, Jun 13, 2023 at 08:26:26AM -0700, Jeff Xu wrote: > > + more ppl to the list. > > > > On Mon, Jun 12, 2023 at 6:04=E2=80=AFPM Jeff Xu w= rote: > > > > > > Hello, > > > > > > There seems to be inconsistency in different VMA fixup > > > implementations, for example: > > > mlock_fixup will skip VMA that is hugettlb, etc, but those checks do > > > not exist in mprotect_fixup and madvise_update_vma. Wouldn't this be = a > > > problem? the merge/split skipped by mlock_fixup, might get acted on i= n > > > the madvice/mprotect case. > > > > > > mlock_fixup currently check for > > > if (newflags =3D=3D oldflags || (oldflags & VM_SPECIAL) || > > > is_vm_hugetlb_page(vma) || vma =3D=3D get_gate_vma(current->mm) || > > > vma_is_dax(vma) || vma_is_secretmem(vma)) > > The special handling you mentioned in mlock_fixup mostly makes sense to m= e. > > E.g., I think we can just ignore mlock a hugetlb page if it won't be > swapped anyway. > > Do you encounter any issue with above? > > > > Should there be a common function to handle VMA merge/split ? > > IMHO vma_merge() and split_vma() are the "common functions". Copy Lorenz= o > as I think he has plan to look into the interface to make it even easier = to > use. > The mprotect_fixup doesn't have the same check as mlock_fixup. When userspace calls mlock(), two VMAs might not merge or split because of vma_is_secretmem check, However, when user space calls mprotect() with the same address range, it will merge/split. If mlock() is doing the right thing to merge/split the VMAs, then mprotect() is not ? Also skipping merge of VMA might be OK, but skipping split doesn't, wouldn't that cause inconsistent between vma->vm_flags and what is provisioned in the page ? Thanks -Jeff Xu > -- > Peter Xu >