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 X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A058EC433E1 for ; Tue, 14 Jul 2020 16:45:11 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6CAD320656 for ; Tue, 14 Jul 2020 16:45:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="hpaIcJRY"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="pfNUm5sb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6CAD320656 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=a+VtrF/veqLtHunhACpjYX5f2eUSgIgWAsSd5IK4nWw=; b=hpaIcJRYSr40TrGMDYZVCc1dM dWGmxjSnJseXWrmmyL8bvUP8MNVNn8TIz5MiycuHtBY/ZtFX/4E2yD58QXnLns+vtSj/qjFhkCjOu 0CIvk0hyBXlUM+mQMlpaJ28w2q6AB6B2kt8IXbOISsGLCTOhVhms1rYqxUody7or6rw47IEbjVOv2 mRcTPXPFLGi9rmORT/fkSrOaj+FqXryqZGtfZkpfPZDXQdPqgkAhAhUqnA9KGUlLl/Z47k8eoEK9t AQQmAn232yy4ZsQYTXIGfumUepDMLW8vQYPLAJFSILczBjGXfidqz9hfyHdQabG4gHipLLXSMvxOY 6jaxFcdyA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvO39-00043T-Db; Tue, 14 Jul 2020 16:44:59 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jvO36-000427-1l; Tue, 14 Jul 2020 16:44:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uxJ0B4NAox0pi048pE6kICiISqhTtULxJ9O1+AK0TzY=; b=pfNUm5sbcnKckbbkuHgpG1iUb PG9jFr4aLHtB0TNVGz7S+w7TZeuO8wzbUK6HYdd9o0z98jWuTA0hxnSx79z5aqUzOmzQEE6gYtB1k AbmjYvt7SQIAHovkUz5M+dyZnwHMfuh1OaOej9C3YdgUehNEobmexCAmqrslD2JxSn1ySJIM/ASI7 uDAuZ2Eg5VP0CLP4JEq/Nvug+u9/hGBcAGSyRBRiVLloqHAPSl/MsUpRaZz9dVHSvjHjE4FW1lB25 n9tNBfwwIM4n5h+ULkbnIEoCH9xoRNhWnlndUCnxL0mIOM59zrkDaM0Ft9W4vyzmWvxCCPRN4HSFx /0qyLCjHg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:39470) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jvO1J-0005XY-I7; Tue, 14 Jul 2020 17:43:05 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1jvO0z-0007Sh-7G; Tue, 14 Jul 2020 17:42:45 +0100 Date: Tue, 14 Jul 2020 17:42:45 +0100 From: Russell King - ARM Linux admin To: Peter Zijlstra Subject: Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper Message-ID: <20200714164245.GE1551@shell.armlinux.org.uk> References: <20200714094625.1443261-1-jarkko.sakkinen@linux.intel.com> <20200714094625.1443261-2-jarkko.sakkinen@linux.intel.com> <20200714102826.GB4756@willie-the-truck> <20200714112927.GV10769@hirez.programming.kicks-ass.net> <20200714130109.GX10769@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200714130109.GX10769@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200714_124456_188935_66A78BF3 X-CRM114-Status: GOOD ( 25.45 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , Kefeng Wang , Paul Mackerras , Zong Li , Andi Kleen , Paul Burton , Michael Ellerman , Vincent Whitchurch , Benjamin Herrenschmidt , Petr Mladek , Brian Gerst , Andy Lutomirski , Thomas Gleixner , Jiri Kosina , Anup Patel , Linux Kernel Mailing List , Philipp Rudo , Torsten Duwe , Masami Hiramatsu , Andrew Morton , Mark Rutland , "James E.J. Bottomley" , Vincent Chen , Omar Sandoval , "open list:S390" , Joe Lawrence , Helge Deller , John Fastabend , Anil S Keshavamurthy , Yonghong Song , Iurii Zaikin , Andrii Nakryiko , Thomas Huth , Vasily Gorbik , "moderated list:ARM PORT" , Daniel Axtens , Damien Le Moal , Martin KaFai Lau , Song Liu , Paul Walmsley , Heiko Carstens , Alexei Starovoitov , Jarkko Sakkinen , Atish Patra , Will Deacon , Daniel Borkmann , Masahiro Yamada , Nayna Jain , Ley Foon Tan , Christian Borntraeger , Sami Tolvanen , "Naveen N. Rao" , Mao Han , Marco Elver , Steven Rostedt , Babu Moger , Borislav Petkov , Greentime Hu , Ben Dooks , Guan Xuetao , Thomas Bogendoerfer , "open list:PARISC ARCHITECTURE" , Jessica Yu , "open list:BPF JIT for MIPS \(32-BIT AND 64-BIT\)" , "David S. Miller" , Thiago Jung Bauermann , David Howells , "open list:SPARC + UltraSPARC \(sparc/sparc64\)" , Sandipan Das , "H. Peter Anvin" , Amit Daniel Kachhap , Tiezhu Yang , Miroslav Benes , Jiri Olsa , Ard Biesheuvel , Vincenzo Frascino , Anders Roxell , Sven Schnelle , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , "open list:RISC-V ARCHITECTURE" , Mike Rapoport , Ingo Molnar , Albert Ou , "Paul E. McKenney" , Josh Poimboeuf , KP Singh , Dmitry Vyukov , Nick Hu , "open list:BPF JIT for MIPS \(32-BIT AND 64-BIT\)" , "open list:MIPS" , Palmer Dabbelt , "open list:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote: > On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote: > > So perhaps the answer is to have text_alloc() not with a 'where' > > argument but with a 'why' argument. Or more simply, just have separate > > alloc/free APIs for each case, with generic versions that can be > > overridden by the architecture. > > Well, there only seem to be 2 cases here, either the pointer needs to > fit in some immediate displacement, or not. > > On x86 we seem have the advantage of a fairly large immediate > displacement as compared to many other architectures (due to our > variable sized instructions). And thus have been fairly liberal with our > usage of it (also our indirect jmps/calls suck, double so with > RETCH-POLINE). > > Still, the indirect jump, as mentioned by Russel should work for > arbitrarily placed code for us too. > > > So I'm thinking that something like: > > enum ptr_type { > immediate_displacement, > absolute, > }; > > void *text_alloc(unsigned long size, enum ptr_type type) > { > unsigned long vstart = VMALLOC_START; > unsigned long vend = VMALLOC_END; > > if (type == immediate_displacement) { > vstart = MODULES_VADDR; > vend = MODULES_END; > } > > return __vmalloc_node_range(size, TEXT_ALIGN, vstart, vend, > GFP_KERNEL, PAGE_KERNEL_EXEC, 0, > NUMA_NO_NODE, _RET_IP_); > } > > void text_free(void *ptr) > { > vfree(ptr); > } Beware, however, that on 32-bit ARM, if module PLTs are enabled, we will try to place the module in the module region (which gives best performance) but if that allocation fails, we will fall back to placing it in the vmalloc region and using PLTs. So, for a module allocation, we would need to make up to two calls to text_alloc(), once with "immediate_displacement", and if that fails and we have PLT support enabled, again with "absolute". Hence, as other people have said, why module_alloc() would need to stay separate. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv