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 C61B2C02194 for ; Thu, 6 Feb 2025 16:37:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 389556B0082; Thu, 6 Feb 2025 11:37:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 339276B0083; Thu, 6 Feb 2025 11:37:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 201596B0085; Thu, 6 Feb 2025 11:37:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 025216B0082 for ; Thu, 6 Feb 2025 11:37:41 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A3B294BB5F for ; Thu, 6 Feb 2025 16:37:41 +0000 (UTC) X-FDA: 83090075922.29.DD0A053 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf12.hostedemail.com (Postfix) with ESMTP id A684640005 for ; Thu, 6 Feb 2025 16:37:39 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="pv/P/fPM"; dkim=pass header.d=linutronix.de header.s=2020e header.b=Yr1rKdJF; spf=pass (imf12.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738859860; 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=1cKpi3TqgXVRtiUpDMLIZvQ3+RhRyWRW43y/M0D5WBE=; b=LpGMJPJWWNA+4Rs9ur7CIVTZA3Al/qWP+SYfqacZWdiKxQNN1cOt7Lx44zcKha7JpKMTon AN1DI+xl7Hf3EyKHMLiJC0Yj3+/IkTLOKBQwFCx9r942qgFaTZ7TW/39LaoQXUGz4nmWQr ZHTaQ3YBvEbRqQ02OABffgZ43n0MrbQ= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="pv/P/fPM"; dkim=pass header.d=linutronix.de header.s=2020e header.b=Yr1rKdJF; spf=pass (imf12.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738859860; a=rsa-sha256; cv=none; b=eNKAy4W6U9lHK7f3XBEbCOmp42uJMC2NSo27JAEF6OB/FI8gBnjrpZPyqBIx7WiM0Cmv9p PUXqQLkpPshH/wPmC6Nu7EIDReTj+bP/NsAoD3IYSKoZC4tRp8hD+FojjM+NriiRPLs8/l Qail1ALVhRofsVwFmme3ALZZuG3rOHc= Date: Thu, 6 Feb 2025 17:37:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1738859857; h=from:from: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; bh=1cKpi3TqgXVRtiUpDMLIZvQ3+RhRyWRW43y/M0D5WBE=; b=pv/P/fPMf5uh2H3P7A82LYI0NFBgvhnOb3HhM2tHkxgj6s8zvJHb/2NiLSVJqEEcDC53WS O3Pk6tlW93BAUfpLCqlE+bOlZd6P7wzTlu6DvfQ41MJ3HguwzCrt2UbsPHfa7dMOVX4QB3 12bNbfX+K1zFkDk34x8kXWr06cuCX1Qsl/PxbPHgGLG97XLfSu253zId1WjaGinbETVo4/ spfF9ebEW7vnGIEyoJrQyJSHl0PDAuSoE/tm37GGgjMGMAiO9pmRfC58Nv8v7Eyoid/Blx PVdMEVP1ynOljbR+sYtunFBv5FbhtjlkV0FzQNvFwNohQ6iHXAThyHDPeVldEg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1738859857; h=from:from: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; bh=1cKpi3TqgXVRtiUpDMLIZvQ3+RhRyWRW43y/M0D5WBE=; b=Yr1rKdJFhTBpl9ZuDGcyRFDeMRr3Ci5sDxWUnGLuinFF6cpe7/u/+obL4UJDR6PchjhujV LFfZefoUf0eFbzAA== From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= To: enh Cc: Jeff Xu , Pedro Falcato , Benjamin Berg , Lorenzo Stoakes , Kees Cook , akpm@linux-foundation.org, jannh@google.com, torvalds@linux-foundation.org, adhemerval.zanella@linaro.org, oleg@redhat.com, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com, ojeda@kernel.org, adobriyan@gmail.com, anna-maria@linutronix.de, mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net, hch@lst.de, peterx@redhat.com, hca@linux.ibm.com, f.fainelli@gmail.com, gerg@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org, Liam.Howlett@oracle.com, mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com, rientjes@google.com, groeck@chromium.org, mpe@ellerman.id.au, Vlastimil Babka , Andrei Vagin , Dmitry Safonov <0x7f454c46@gmail.com>, Mike Rapoport , Alexander Mikhalitsyn Subject: Re: [PATCH v4 1/1] exec: seal system mappings Message-ID: <20250206172243-bec6d9b7-c0b5-44af-908d-c7190b63c0e4@linutronix.de> References: <7071878c-7857-4acd-ac27-f049cbc84de2@lucifer.local> <2e5de601da34342d8eb0d8319dcf81ff213c7ef0.camel@sipsolutions.net> <20250206135150-6c770e7d-9af8-4924-b760-82cff5092586@linutronix.de> <20250206154810-8b7bf2b4-435c-4930-a787-f9238cd0045d@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A684640005 X-Stat-Signature: zsk1d9pbuzgeebdbwoe1sey1dikep71p X-Rspam-User: X-HE-Tag: 1738859859-772806 X-HE-Meta: U2FsdGVkX18tRHqGnBbKZT8MEzNChJeZP59qCDcpWGv8TTYNd0qXzsFC+HjZBCWY6ecHhFaW36XcyAG+Enl75Bxupni/f8vJurUpcO1PXclekT1JO61JWu2WYbKjNCAheEtQliSfJN0S2OM0fOCxIPKo1cHPY0BF0xULaVrFROCpIfNwi+H/h5dYQqMD6Vmjam+uG6ipdOuoq8nQgy5KoCy2hJgp6sgmbLEG9WjGAdaoUmvTd+y5stVITwosw0gxpC4Bx/FWRNz2Lf+TLiRg74vhpkdgSmoQ2Sg7cSARFFIZ3YxJexWSmCVwtJ6Q01NFN3EPAi9TDRx11SXmxU7NGJP7gruXiYBg+pP+9xTfoA0s4cdg6QJuBiLl/CBFZsy+D9yit/jlJZfphiJ/BJO9b5S9dg6RQg3ePaoyGWXt/am2t2StrZtgISgNYiCQL7AYA1Ave5nq+4OVdoDZEDd0sJv6nggcR9/YNHqeBL8iTVi1K8JzkhgNADVLRFBybYPr3sfAnKrR9uKmJVtsYmAcZ6vNNiHjPEImkqWyXdvnY/nrR2Whpf2NLJeKRrpXy0dmGAsJofOutBOx4LVQ0rbFkkQKRddEjU5+ODXB+NNercENOGvGQSMlg/eIbsUNwCGNOm709eqL10fzcG3iw2rz0i9K5cC4O/Wb6gyqXpYszJR8xN/CUgMDRHiq4r+lt9j2uc/c37k8LMskWc6Xv70kNe282H8Rzvu2JSyefEs4s8O9QdcNIJ6SwjVO/5pRR9v9QFA6V+I0aFUamr5j1q1Aowrnn06R7WlQ+HqYZVqvXynhCK6/Sz8PdWjIsTOzmL6b9I9V5QkTCuojMt7Bw1V4DRfByNpD4AMorAkQzThVTECmohQ1960HUT24c2n2Bx+IcPIL45R6s36rmSjo8gnM0JLY8/W54XlpQ0QOwOFjJg3BpbRz9RrTOPIMvI5yPENYZujYdjrfUWPLT1GUdqt SSuAProj 5YKq71gRaEAplrTjI5pDxkMuyXjkaG9jJ83qz25u/EblH48IxmP8XRPwRhnu12EhIorWL1HOMr+22SrndqJ6cm+bU2wjAolhD3YPVGEo7ZJ64NvQXRt7sgjnipGaBBcQHFCNxHYrdtM3Fs1HTkBc4wjHulq+hf0ohWFQCQjSYf3Oc/EcCi58t0x3AycewBGzWJMiIrN/AvHgUMo6xvma5tQlqHoeLBm4TqyY+vD/fHDzEdZK847K812w5fXRZL+3usuC88J4h9KK9lv1zIkYeM9rew1IrjvZPAtUtBu1AQ4/xIl35kkSSK5zSqfRS5yNe5rpMQrf5k7aSdhvxRicvMXzBUwmICSqpkbNUTfjxEeR+IOMGNr3aknviP/diXgu4EUZupFQk9QvBNZN/DryqHS4Qx7FipaHJn2D7it3mNIxM326BVW7HadhymnxCKoPHOnBgJpLHCsU763OrIRzDMA9MBXvhiM8wPuDzEtBCSHmPCpXyB95zohY2SwLczzNa6lnZjMibap8K6XJ6q3WfnUhAZhIXPZkjzS3cJ0FaPZJDzPiRVmjBgNzksp7SlgNg8r7W X-Bogosity: Ham, tests=bogofilter, spamicity=0.000075, 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 Thu, Feb 06, 2025 at 10:51:54AM -0500, enh wrote: > On Thu, Feb 6, 2025 at 10:28 AM Thomas Weißschuh > wrote: > > > > On Thu, Feb 06, 2025 at 09:38:59AM -0500, enh wrote: > > > On Thu, Feb 6, 2025 at 8:20 AM Thomas Weißschuh > > > wrote: > > > > > > > > On Fri, Jan 17, 2025 at 02:35:18PM -0500, enh wrote: > > > > > On Fri, Jan 17, 2025 at 1:20 PM Jeff Xu wrote: > > > > x86 has two additional vvar pages for virtual clocks. > > > > (Since v6.13 even split into their own mapping) > > > > Loongarch has per-cpu vvar data which is larger than one page. > > > > The vdso mapping is however many pages the code ends up being compiled as, > > > > for example on my current x86_64 distro kernel it's two pages. > > > > In the near future, probably v6.14, vvars will be split over multiple > > > > pages in general [0]. > > > > > > /me checks the nearest arm64 phone ... yeah, vdso is still only one > > > page there but vvars is already more than one. > > > > Probably due to CONFIG_TIME_NS, see below. > > > > > is there a TL;DR (or RTFM link) for why this is so big? a quick look > > > at the x86 suggests there should only be 640 bytes of various things > > > plus a handful of bytes for the rng, and while arm64 looks very > > > different, that looks like it's explicitly asking for a page (with the > > > vdso_data_store stuff)? (i've never had any reason to look at vvars > > > before, only vdso.) > > > > I don't think there is any real manual. > > > > The vvar data is *shared* between the kernel and userspace. > > This is done by mapping the *same* physical memory into the kernel > > ("vdso_data_store") and (read-only) into all userspace processes. > > As PTEs always cover a full page and the kernel can not expose random > > other internal kernel data into userspace, the vvars need to be in their > > own dedicated page. > > (The same is true for the vDSO code, uprobe trampoline, etc... mappings) > > > > The vDSO functions also need to be aware of time namespaces. This is > > implemented by allocating one page per namespace and mapping this > > in place of the regular vvar page. But the vDSO still needs to access > > the regular vvar page for some information, so both are mapped. > > ah, i see. yeah, that makes sense. (amusingly, i almost quipped "it's > not like there are _that_ many clocks to go in there" in my previous > mail, forgetting that there are effectively an unbounded number of > clocks thanks to this feature!) Tiny clarification: The additional, namespaced clocks do not use additional space in the global time vvar page. They live in a dedicated, dynamically allocated, per-namespace page. So the used space within a vvar page does not change at runtime and can never run out. The amount of vvar mappings per process is also constant. The namespaced time vvar pages have the same structure layout as the global one, but not all fields are used and some are used differently. Specifically the namespace pages only contain the offsets to the base clock and the dynamic clock data is read from the global page.