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 A29EDD637A3 for ; Wed, 13 Nov 2024 17:44:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD6B06B00AC; Wed, 13 Nov 2024 12:44:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D871F6B00AD; Wed, 13 Nov 2024 12:44:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C4E8A6B00AE; Wed, 13 Nov 2024 12:44:39 -0500 (EST) 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 A78356B00AC for ; Wed, 13 Nov 2024 12:44:39 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 225C6C0CB5 for ; Wed, 13 Nov 2024 17:44:39 +0000 (UTC) X-FDA: 82781794284.09.AEB8A02 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf27.hostedemail.com (Postfix) with ESMTP id 1576340004 for ; Wed, 13 Nov 2024 17:43:52 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=UA4QMzzR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of jannh@google.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731519700; a=rsa-sha256; cv=none; b=OPR1KAjyzd+nfo0c0QHK8jwpPlNFsP10i9JSXIAsUUYHyqEPEgL/ZYtJcUS5q43kCYRSsd zN8K/r3CrtoDehQnyKC6du4b9WsU6M4Sw5Z1cIiFiv7HgZsgNaZMt5KHtqbEe+DRGyA+5y jzyd4fH+FTrjbKq5JHGWo232cz7aSt8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=UA4QMzzR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of jannh@google.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731519700; 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=Di+iKJ5akzTFP1IjKCqjyy6r9Jqh1xsxmJVtI0c5XMw=; b=XVXNrpkz9vSKAYFi8EjMuWXux/P/MxWTYCreHyq7W4dFIvqq9TIZ6Bsdwn9i3eOjFzp3eE I8m1bjyUQDdaHNNjhumlxbaM//D5LstHtF3NFfDC+pNsfiAAUATt2VPMFgkJ3h4s+J4KUV DZLcDuRR5Ny5xP7mZvbMHeU0mskvOOw= Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-53da266cf37so6555e87.1 for ; Wed, 13 Nov 2024 09:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1731519875; x=1732124675; darn=kvack.org; 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=Di+iKJ5akzTFP1IjKCqjyy6r9Jqh1xsxmJVtI0c5XMw=; b=UA4QMzzRSwfw66I9YoCEGJ1mc3/PYOjlChOZJCOq+OW2xHK5U7nKhM17bMxs8SDcgA A+v23VGF26hwu92PR9D3TrI1k97l/rD6fYdxvEbaOPnquFAN/jlzgE6sj5KIbUKfmo+o avwRgiq6eiHI0XxVxH/YMketdmqfuTZmiuJbwpppOJ58BlWCtyuX5b9/9ThW8E/g3Mee Qnwl6TvWR+04UsHw0NiFNGM+m9IPUQVWf3zSLcXXy7a4aJ9stDhk0zhTvcSaVEDiwrDi J5YYmAS7NE2e750kHqLFrig+z7DRrPwxG7uovKA4+zl4fGkIEE/yKvN4kAhBsUGe8tKC HycA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731519875; x=1732124675; 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=Di+iKJ5akzTFP1IjKCqjyy6r9Jqh1xsxmJVtI0c5XMw=; b=AVZyTKyFefjLRicNd2TWP1/f6fGsTQYAgpUexW7qNLajPKoF7cll5bBG0s26uaPs8r AqxDe6edx7Hp9DyH1qPfMb8OT2k4d1nNXbmmUErCJ6WPrjw3viiuMkkNggktHdkxrAcy GUAPVwd+VQcaBVvL01ruIrnW/VZq4LRA5yGJd+aChZ+1W8xUNPpy7aA2Vg2UCNrfVkg5 6j0YR5J8KhfFHNed0riJhE5eMbJCyHcDOIpaYmbd6lC7K8wZGNCJ6n1/StQCwI0uniIu wQKjhtT0j4Zc3zT+5PQeD85uVWnge/optmrLSEeaOrrMLGNFZnItmpsSJici7VaCERTt 8qxw== X-Forwarded-Encrypted: i=1; AJvYcCWcazvbN3AnabV7O0JWfNDrZ97QBwZB0MmTGIcIpTkGAEozfFLRd3rk9GJze/SOTSuTxseaS4X4fQ==@kvack.org X-Gm-Message-State: AOJu0YzATrzvWsZ9AF21m9J9U/z1fHIozHy5Ki2bunbPIDe2kEdXJ09f 9GzxkhiN13D9wh9vOnWFmxA3Xk/wf6zt+JVB92Ndc4RzcQB+eR5fWrrnqPw8h6rNhypaJ2xbPUv 28Wn4CU4lDF8W1vswvHxtPwBxTddBTsE3w3Xa X-Gm-Gg: ASbGncu88Za6w/57U5DV51prDtysY2o9jsJHT9xudiscbiZzhaeQ+nOP5APnRDXJcNC pQ/bckaMPMriM5A6it6EJgBbmwMln2EmRXXdAsL6VWn/Mz3OedRyV+aTQ0uD+ X-Google-Smtp-Source: AGHT+IEBiRX+iakj03mwhRodl8EB4ddlvW0A0JNFLYItqjRlt/va0erAr2MtetPxwlyJPF24ToOICU0mFNtQbJtF85E= X-Received: by 2002:ac2:4438:0:b0:539:d0c4:5b53 with SMTP id 2adb3069b0e04-53da0736535mr143602e87.4.1731519874758; Wed, 13 Nov 2024 09:44:34 -0800 (PST) MIME-Version: 1.0 References: <20241108135708.48567-1-lorenzo.stoakes@oracle.com> <3593f7ab-c37d-4c1d-bf2f-e47c30bb5d2b@lucifer.local> In-Reply-To: <3593f7ab-c37d-4c1d-bf2f-e47c30bb5d2b@lucifer.local> From: Jann Horn Date: Wed, 13 Nov 2024 18:43:57 +0100 Message-ID: Subject: Re: [PATCH v2] docs/mm: add VMA locks documentation To: Lorenzo Stoakes Cc: "Liam R. Howlett" , Andrew Morton , Jonathan Corbet , Vlastimil Babka , Alice Ryhl , Boqun Feng , Matthew Wilcox , Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Suren Baghdasaryan , Hillf Danton , Qi Zheng , SeongJae Park , Bagas Sanjaya Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: ins14oqx99cumkz9oiswb7bz793ph8xm X-Rspamd-Queue-Id: 1576340004 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1731519832-431623 X-HE-Meta: U2FsdGVkX1/AVqy5DGfDDzlV7mPPNepq4p+SPEi18lsvo/H/609qkN5QQUvQaa/+gbus1FDViml2QOGoW/AobCknTa6lF/WHaIelZiRmNtLAP39fT1NEnCUCEAOTwEJ7402SADHIuSEKIGe67gfg7u28cJSqXExjI/rleS9dmZ/juG9hoNChyRGtftupVgCj9Gzg9EaHzraV5gEhsQmGhiRlwf0rytyV1weapNsR7vxNXmgxXDROjFwDbbWorLbJw2NcgDGUB/1KWx6k7khS9BAWAliJefWSVyWasti7OHydkS7zgfbBVreZgFLOKaWTxqZ9jbViEIvsCSIruqjUFIKXISdQdLxGhtXoCPUb3dDn2s1qm0rpjnxTvLeSoATWUkRLv5W3pJytYBg+lgXpMB7Sgjm5UbP7Wgv4E1qdNbOgGAl584KG4UxzPdHmcHC1p15FxMAtDEKYtyDBVH48alOJmMqOCXU2NRKD5LlPUwggN9HLj0o+yfmbaoJGu1OyFUM9gHhO/feGGNY6g1n3n0dACaNra2T9BO7PrHEkrw2n16tGW9+G7gjyEISleAA8cEXkhcmSxSMh50GiuGVVS6erJi+hiKoKlktWx/MO1N3uqiw01G2FJsdmW1zhvlrU38Alt6PwSVhJ0otdX40eHVMwmCMQ8s85IRR5ivhe4HvG3F+cLxCyHQsgZiGv207F83RZoGDjG1Vy4XCfJxWO5Mh5q4y58M4nzLrF0TPEvdRUSpGqxilMnI640pVGRxZDqiXCAyPzEhrsxoUz73ZMMClWICBM3K3SWq79CopsU511N0h25gRWQU3ibm4cQWUevmxaD9sK1IQB3p7nzizRtUcIyqou+xgvUO7gFM03T7lUugA6dupUEX/3RuREUp8+cBJ8z3WRbvu+swAQLakJrzUoZqyX4RvlNWHvRutO+bxQusU2aMkPY1PaB0YfLoV7lyBayAzObpXAQvJqkJc U3CyLMeH aEEtUOvMygFGkq2KzkNQ4aIRCQj1r+tQyd5KUbH4rsMu3gDpkGi80xqGFlMfohJb7JEm/870mBikmc8tAFN0I5T0k8t4EPrDD+DKCStrqfhExKZSfaEnM/FAI/IpfvkLl/hAfmhqZAyBWGE6R/fhoUcCmfxY7uk/Rmw+c8agMHdCGKyzTkK8W78IBSGvKoJ7S4rcv78y3fHsveGDDKBhhB+rBODYMWJ4ENQxV0cvpCgjvXwWdmkxXg8/cmZa1qTTn8MjDwCSm7bzgaxpzGBXKmgDE5/pNv6suCdfV 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: List-Subscribe: List-Unsubscribe: On Wed, Nov 13, 2024 at 4:44=E2=80=AFPM Lorenzo Stoakes wrote: > On Tue, Nov 12, 2024 at 10:15:44AM -0500, Liam R. Howlett wrote: > > * Lorenzo Stoakes [241108 08:57]: > [snip] > > > +Each mm object contains a maple tree data structure which describes = all VMAs > > > +within the virtual address space. > > > + > > > +.. note:: An exception to this is the 'gate' VMA which is provided b= y > > > + architectures which use :c:struct:`!vsyscall` and is a glo= bal static > > > + object which does not belong to any specific mm. > > > > vvars too? > > I'm not sure if that's the case? For instance for x86-64 we have: > > /* > * A pseudo VMA to allow ptrace access for the vsyscall page. This only > * covers the 64bit vsyscall page now. 32bit has a real VMA now and does > * not need special handling anymore: > */ > static const char *gate_vma_name(struct vm_area_struct *vma) > { > return "[vsyscall]"; > } > > With no reference to vvar. Also vsyscall exists in a kernel range, and vv= ar > in a userland mapping (along with the vdso). Yeah, there are different gate VMA types depending on architecture (arm has "vectors page", x86 has "vsyscall", ...), but vvar and vdso are just normal VMAs set up at some point in execve().