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 E0638C18E7C for ; Wed, 26 Feb 2025 16:35:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 704B36B0095; Wed, 26 Feb 2025 11:35:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 68E586B0096; Wed, 26 Feb 2025 11:35:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 506936B0098; Wed, 26 Feb 2025 11:35:03 -0500 (EST) 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 2D93D6B0095 for ; Wed, 26 Feb 2025 11:35:03 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7C951161D47 for ; Wed, 26 Feb 2025 16:35:02 +0000 (UTC) X-FDA: 83162645244.08.A48FFD2 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 6CFD6A001D for ; Wed, 26 Feb 2025 16:35:00 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BstER82s; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf15.hostedemail.com: domain of oleg@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=oleg@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740587700; a=rsa-sha256; cv=none; b=D8HINTqD+QkpA3HnOIMNyI+76LEGz3325JQFeEMoYpuT49IxDTQl6RSNsZQTd4DL1NuG3D qmVFK5ltCBMR+bXttYlLBTTL+MSCaDGXQlL5j9K14N/MDn5715z6KkIRZYGnaebnXJVDYt 37BRdX7wpfODK1bZgt5KVV2RcHjq8c4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BstER82s; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf15.hostedemail.com: domain of oleg@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=oleg@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740587700; 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=yyEeKTSwKpsNdlVwXwewsRo+Wp2oqTEyHSu9r2lJIi8=; b=VySWhUvzSnUsCUz8+Hcs9ZBXgJc5HzhklYTYcs7Fse8F7uLdPtMyPj/Zg2viUAho7YYt4K RtgdKZVSgKA5gSuGFpgbLdSmksEO1Le5ERKERjuN9Nb+AwAx4ApECjgT0XhT9QH4a2lnOD Hzru6mh1A4XnWp78+rSmsgtL8gM2VcM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1740587699; 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: in-reply-to:in-reply-to:references:references; bh=yyEeKTSwKpsNdlVwXwewsRo+Wp2oqTEyHSu9r2lJIi8=; b=BstER82sJE8X2S0mu8J7ziczEajMVzw4GQrKoqIHTPGfkVzo6rTA7njnur7WLcRn7h3S+H yUFcFc0tmq5KQUPnbBNtee+jlLiSCQEdlAJ2zwrmxbY12AuWeHLn754303PjvAB9Xidwdg GQpAhczwcPFDLRbpvQaDMdLKb9GhffA= Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-687-K_6v7QjvOk28uSUtvhbxJw-1; Wed, 26 Feb 2025 11:34:55 -0500 X-MC-Unique: K_6v7QjvOk28uSUtvhbxJw-1 X-Mimecast-MFC-AGG-ID: K_6v7QjvOk28uSUtvhbxJw_1740587689 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C305C193578F; Wed, 26 Feb 2025 16:34:47 +0000 (UTC) Received: from dhcp-27-174.brq.redhat.com (unknown [10.45.226.247]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with SMTP id DB74919560AB; Wed, 26 Feb 2025 16:34:30 +0000 (UTC) Received: by dhcp-27-174.brq.redhat.com (nbSMTP-1.00) for uid 1000 oleg@redhat.com; Wed, 26 Feb 2025 17:34:17 +0100 (CET) Date: Wed, 26 Feb 2025 17:33:59 +0100 From: Oleg Nesterov To: jeffxu@chromium.org Cc: akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, torvalds@linux-foundation.org, vbabka@suse.cz, lorenzo.stoakes@oracle.com, Liam.Howlett@Oracle.com, adhemerval.zanella@linaro.org, avagin@gmail.com, benjamin@sipsolutions.net, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com, hch@lst.de, ojeda@kernel.org, thomas.weissschuh@linutronix.de, adobriyan@gmail.com, johannes@sipsolutions.net, pedro.falcato@gmail.com, hca@linux.ibm.com, willy@infradead.org, anna-maria@linutronix.de, mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net, peterx@redhat.com, f.fainelli@gmail.com, gerg@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org, mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com, enh@google.com, rientjes@google.com, groeck@chromium.org, mpe@ellerman.id.au, aleksandr.mikhalitsyn@canonical.com, mike.rapoport@gmail.com Subject: Re: [PATCH v7 6/7] mseal, system mappings: uprobe mapping Message-ID: <20250226163359.GB17833@redhat.com> References: <20250224225246.3712295-1-jeffxu@google.com> <20250224225246.3712295-7-jeffxu@google.com> <20250226162604.GA17833@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250226162604.GA17833@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 X-Rspam-User: X-Rspamd-Queue-Id: 6CFD6A001D X-Rspamd-Server: rspam12 X-Stat-Signature: 1wdbf5ep47wuxsb9p5h6k3bj5hgozekz X-HE-Tag: 1740587700-637669 X-HE-Meta: U2FsdGVkX182kaJic13MjY9F2mDhV0G9qEHPPGuSS4pHTGerx4Q1p+/OWODrb4sFgv61xrQfspcOz+lPkpSNuulAP0Gi2IK9lZoJE7P6aLt/ogIbEyGYUbHpKYuc0n3IPZY4+mtOsJBF/EnUBjqQqrkq8I7Uu2faxYb8vFghWYSogpfkStpITdOgCMO0tczXc7ycFkby1+cAEsBvHNbzQ5KZW6rOAd3nphq6VrlBKxK7k2tevWz4zYOGDcexqhR6dhcHK0Od5R3UO+nW1c9esBjhVfSStZkQJ8vzkyZP/z82LMD2AT+u9eMOwYVgj0sW4YnKgC7Zx71U6bFg7XCx71zy5FKdIK8Ci6FKNAwQtf14ZMpwFQNjh4QXu+2tysGYb6bvCe9OzhAUu9m4CZ54JCyH2APZ0hft/2P/eF511m93i5XeWjh2bZuGQ0O/14AlzufF0P52ZC2NodGwe62cba/QBjiXWxa5pCzraxEZf3IojG3qylzq525/7VVpaW/AAwpQLnseIYFhxeLXAHH8OCt+lz4eYL8vGorDzOkDcAwKmCzhzh6pXT4iJPpNRNlpV3V+h59ki9ezOtJs5vTSGDmBueWAMeou1U2ZOPnqWftAy5/Gh8SM892Vw9IP66fOaSkW78wicmQQicBKwUGHaWzbYwNErG4COOJ6kTV59WovM14Vj+OcJUDElBuA6dd/YsKG7whMWQVvSgs1NRa9mxSj/Q+FIVF6KMl2GUXyAzCEqzYB6jNPfkvQj2/RMZJmtEQDdeDwXhAmYcmhXc9YnUVHdSP5G3aAuiCxn5fqLYRGANQ4A45lOFdnkBCd9tlYgjxnh14R26+pWv07fYX12BioBdmsjqHieO2u4e/Xmw9RKwaFYAioEcOEKik/9DUL4ufkqVD4VD7B4dprSUSn9KwrMPRboS1veLhpQcIxGhdX1zEZHWEdenOBJ9IF3nKV0XPA91zOJcAxvxqiy7i TE9Dkvfy QHd3wxYqhnFC/3B0EssEFehdEbFE8dYY5MzJN5pr/AiRFe+nu191R6/Lcl9gvr/yIsKaprXYlxZaL84et+LPVAsp4nvPCrgmVYrUGZ7U4UrR1SFU9f6mHuTGqfJ7GS6ey888HQf2fuahdDUI8bhGlBIDRhL+jP/gG95y6ldKGmjO3Kog++2Pa2giI/fDzt1ynpnnB6+T7NBeMlrAh5Xx8QAcG2DtLH3BPGNc4AvOrZu1+DczDGedTFqNmt6wqiQW3ytYldO5h7oDN1Y/XkZZuBB3o/FJSO3yuaVV17QdoWPP0InQtJAnaBfdFin3YVc+35gInyRiQA5VEH/tEnSz7yMLTAxf9k8rYZggT0HVyveHaRaikxOFX1ddBsS+HWEyPc4RGQa0LIcTtAhthbLX2rxG9Ew== 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 02/26, Oleg Nesterov wrote: > > On 02/24, jeffxu@chromium.org wrote: > > > > Unlike other system mappings, the uprobe mapping is not > > established during program startup. However, its lifetime is the same > > as the process's lifetime. It could be sealed from creation. > > Agreed, VM_SEALED should be always for the "[uprobes]" vma, regardless > of config options. > > ACK, > > but can't we do > > #ifdef CONFIG_64BIT > /* VM is sealed, in vm_flags */ > #define VM_SEALED _BITUL(63) > + #else > + #define VM_SEALED 0 > #endif > > and then simply > > vma = _install_special_mapping(mm, area->vaddr, PAGE_SIZE, > - VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO, > + VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_SEALED, > > ? > > But I am fine either way, feel free to ignore. Yes, but either way, why your patch adds "unsigned long vm_flags" ? OK, perhaps it makes sense for readability, but vm_flags = VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO; vm_flags |= VM_SEALED_SYSMAP; looks a bit strange, why not vm_flags = VM_EXEC|VM_MAYEXEC|VM_DONTCOPY|VM_IO|VM_SEALED_SYSMAP; ? Oleg.