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 40970C4345F for ; Thu, 18 Apr 2024 16:14:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B807F6B0088; Thu, 18 Apr 2024 12:14:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B337A6B008C; Thu, 18 Apr 2024 12:14:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A284C6B0092; Thu, 18 Apr 2024 12:14:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 83BEC6B0088 for ; Thu, 18 Apr 2024 12:14:05 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 026291C1A62 for ; Thu, 18 Apr 2024 16:14:04 +0000 (UTC) X-FDA: 82023149250.09.DDDC1E5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id 0FCCE120002 for ; Thu, 18 Apr 2024 16:14:02 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QKWF8JTq; spf=pass (imf29.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713456843; 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=zY84RPfcbQQ19z2BMBg5ttaeSHHSpIHhbwTUEVVeTtA=; b=0j3CFKU0XnJol8B7AU7ucQOrwlOU0e9OwIkxxgZkbHYwlAzM8U44ZxsjgvvWx2FhLmN8hI RfHBji77zxuvuwx8B3uhT2DpwV9BvTwycU0lBQR/7tqnoIqfKfq5m4XJgNEwWPfvICX/Q+ gbZw7EaXgl7hEH9w+b++dpHBNr0sxPM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713456843; a=rsa-sha256; cv=none; b=S0bOQuwOD8Ue2tseigfuMeHhj0SfncRQH+TVHSvHhkYwvss56n8ohwQkas7L+yfvqUrz2v JZekBLrZizo1iUnTD0/fuQlDPVUHTJ/R993M0VCkCp3PMxwPz0JyO3FyriaN7njgIq0S5G 59zcsSdFQfe2jRZL9ObaLt0fObrAiI0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QKWF8JTq; spf=pass (imf29.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 1FF0F61852 for ; Thu, 18 Apr 2024 16:14:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0DE6C116B1 for ; Thu, 18 Apr 2024 16:14:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713456841; bh=q/TFlw8SQh+Cko4nU/ng2SJ+spicGdHxGtHPBf/Abnk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=QKWF8JTqm58INLwGllp0FpCdKA+4HVthmQGojPwlLwz/CzvDupBln2tDa0JxxVT3h 9I7DpSmJ8lOrojowdqSiCh2qcPLKXHcJWahr/LsRKoimlCRLEGzrENrG3o9kFH+usO i5Uoall6+ng5DIWhZcIBvHqNjg1V9YxU/O3gqnfaquqVpvjeUa1Ln7x3DimeC08fFd hg+ro7zsoce8fMGXC9TZUX4AVwsN42ulovUJae+4eeUwyJYlzcMgZJLHMlMif6hKb8 XAy19kJzQAz55LYLEJJVfb5Ee/I081i7hdGhY0gcdzrCOy2SjjHFiLjMG16M8+ZMXw edLWR6CS/8U/g== Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-418fd47a2f5so1334135e9.3 for ; Thu, 18 Apr 2024 09:14:01 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXzGeHGkGGioq6hepKF7hRJ7Za7B4bgQEsdpm/2OoYJoOXrh2MAX4KGzH1mwivtHMacPekuoBgem9eKDy4AQMJ+w8k= X-Gm-Message-State: AOJu0Yw3W/7eTuRVtAjHQc+A2MKHusPuOx//bM0kuiewCXL2jFtZJJxB iLNByEvA1e+OtmwO7O+GnXzOiVR4PuMsQF8TURRn+R02R01KcksTfIt3oiCqAPDPqtlZ7wjpf4S 8K1qfD2QPysHB3gG2Jbaa8ZV7/tE= X-Google-Smtp-Source: AGHT+IHLiDWbpJNv5cpg7tSucX1RJbILlT9QE6EE0zaOt0RsDuLJ8JfO9fqfVmmivnqe0091gRHYHRJJ+tsSYBR5kLA= X-Received: by 2002:ac2:5fad:0:b0:519:569b:361b with SMTP id s13-20020ac25fad000000b00519569b361bmr1973077lfe.63.1713456819439; Thu, 18 Apr 2024 09:13:39 -0700 (PDT) MIME-Version: 1.0 References: <20240411160051.2093261-1-rppt@kernel.org> <20240411160051.2093261-6-rppt@kernel.org> <20240415075241.GF40213@noisy.programming.kicks-ass.net> In-Reply-To: From: Song Liu Date: Thu, 18 Apr 2024 09:13:27 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 05/15] mm: introduce execmem_alloc() and execmem_free() To: Mike Rapoport Cc: Mark Rutland , Peter Zijlstra , linux-kernel@vger.kernel.org, Alexandre Ghiti , Andrew Morton , Bjorn Topel , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Donald Dutile , Eric Chanudet , Heiko Carstens , Helge Deller , Huacai Chen , Kent Overstreet , Luis Chamberlain , Michael Ellerman , Nadav Amit , Palmer Dabbelt , Puranjay Mohan , Rick Edgecombe , Russell King , Steven Rostedt , Thomas Bogendoerfer , Thomas Gleixner , Will Deacon , bpf@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev, netdev@vger.kernel.org, sparclinux@vger.kernel.org, x86@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 0FCCE120002 X-Rspam-User: X-Stat-Signature: o3km7eet3f3yjafrudf77ja7qaicmsem X-HE-Tag: 1713456842-479399 X-HE-Meta: U2FsdGVkX1+1kCeSgazfkVTeF06/gWiodj6Bv5Yr3UIE3tmaw0KzXHS8PFERAhdfkfnGq0dwrABp74XQOzTuRarOkYldnqjRtgfmIrCHuaNamGQ23+cP4nRDOUVYu+jFOxKGHgGAFsponfO5B/wiTB0VOQ4n73E93OdSA5kv9wxoLm+YFp07+xGOYvratSj9c1JWsL5fDJg6fPIn86XwfDYmD2WBV/2YWGdDYJjgsL+D7yYuxgjhfaWhXkoBGwHQv4R1I31FWn9fO3ecDEeYETuyiabW/xpCyOdGK20UCXU6YOF7kvUnUfT2wRjCut29WtPM3Umcv5LouP89jtXPl2p10h/1KFvpgsLXB01Y3HIFXkIoLDY4gA5vElvYdZxBnMeKyfZI+p0zFCuc6n8TTrqT/bq52Dg/A5o7R/0lL0+scwdKh4NI/GclQ9lnv7moaJKp1sghwt02sv03z+23dJ8ehG6+nPszJWle89gBB5i9mFy6tdmCS/sgYcCZucANA05mFlWfBFR1RyaafL7THyDdtS5af2CW26fauFchi0YsuyMtaml/MpeSan1XQMJjSIXm8Q8KsLeZxE+OKEHl0LqAFk5b+O4H9vP/NtB0sUXBNaVJrcTz4LE0K/PuGKS5uqSptGCdcGF3wWSVKJp9jlggdcFL67JeP9LWXMsLq/PhM+MW/aon3yWW6joZ073FqZgYgyGzS3/rT9aJaPrMCXZUpv/AfaNoeBtp9ADi0hajN/DdnIT21PqwkZ9ELsfRquICJeiBKOHcdWausBDY4Xl2Mi3pNCn0VPMPB1Fn8EkXa0ggrPAhzoDh8ppeR/DcbPWCK1Pc8t1Hn/9puqdB8XFAQ4IvGRgIAh4nZQ87xQjdBkDQxlhUUcg/V3/VxgqGJaS8jd3XWEHUcTLZ2RMv7YJsELiJeltPN1nkJec7wPBipkAXw/oaPT7NK7o35eOjzCSg5omh/ggoGYwWNrG WiAqYqq7 CDJK9IegdUKGyG46mdzY5TRJ32oYyJOZ3yKvalZgPYPqZHY3cAvR/5DTJgQcoViYmkz9Eg6RdpZhm0RBpog3JQy+7gooj3p1KpfIyAci+MImTLN+9JubBfqY0qEvNwIPQ7QOOXEm3OgMpnuS96GdswRpDwoI//YEhpISeXPTtITms8vN7LDw8FsVc1NOoeVKylbIFEFdA5zvK6IRjaw2KlfTctBJJW93u2Dg7GlPVG5R3ixJU9mVZGF1JWcma7jVQmpRzMdsfcacaGsLFlSO302mm+MjgRruAYdIlhrlu2TGUbglXlyh5t/selNXEwTT2fWunOhcDrSz7mn+wphTF6I3wqbbEe8YsA4/nKgqY6cbhZYxvrvKu7wt05d3twqGD+FyaKnXzEBLyGXM= 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 Thu, Apr 18, 2024 at 8:37=E2=80=AFAM Mike Rapoport wro= te: > [...] > > > > Is +/- 2G enough for all realistic use cases? If so, I guess we don't > > really need > > EXECMEM_ANYWHERE below? > > > > > > > > > > * I'm not sure about BPF's requirements; it seems happy doing the s= ame as > > > > modules. > > > > > > BPF are happy with vmalloc(). > > > > > > > So if we *must* use a common execmem allocator, what we'd reall wan= t is our own > > > > types, e.g. > > > > > > > > EXECMEM_ANYWHERE > > > > EXECMEM_NOPLT > > > > EXECMEM_PREL32 > > > > > > > > ... and then we use those in arch code to implement module_alloc() = and friends. > > > > > > I'm looking at execmem_types more as definition of the consumers, may= be I > > > should have named the enum execmem_consumer at the first place. > > > > I think looking at execmem_type from consumers' point of view adds > > unnecessary complexity. IIUC, for most (if not all) archs, ftrace, kpro= be, > > and bpf (and maybe also module text) all have the same requirements. > > Did I miss something? > > It's enough to have one architecture with different constrains for kprobe= s > and bpf to warrant a type for each. > AFAICT, some of these constraints can be changed without too much work. > Where do you see unnecessary complexity? > > > IOW, we have > > > > enum execmem_type { > > EXECMEM_DEFAULT, > > EXECMEM_TEXT, > > EXECMEM_KPROBES =3D EXECMEM_TEXT, > > EXECMEM_FTRACE =3D EXECMEM_TEXT, > > EXECMEM_BPF =3D EXECMEM_TEXT, /* we may end up without > > _KPROBE, _FTRACE, _BPF */ > > EXECMEM_DATA, /* rw */ > > EXECMEM_RO_DATA, > > EXECMEM_RO_AFTER_INIT, > > EXECMEM_TYPE_MAX, > > }; > > > > Does this make sense? > > How do you suggest to deal with e.g. riscv that has separate address spac= es > for modules, kprobes and bpf? IIUC, modules and bpf use the same address space on riscv, while kprobes us= e vmalloc address. I haven't tried this yet, but I think we can let kprobes use the same space as modules and bpf, which is: ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF Did I get this right? Thanks, Song