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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 88826C433E0 for ; Tue, 23 Jun 2020 09:37:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2C1F920723 for ; Tue, 23 Jun 2020 09:37:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="YzRmSVna" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C1F920723 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 980106B0002; Tue, 23 Jun 2020 05:37:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 908A46B0005; Tue, 23 Jun 2020 05:37:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D0C26B0006; Tue, 23 Jun 2020 05:37:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0118.hostedemail.com [216.40.44.118]) by kanga.kvack.org (Postfix) with ESMTP id 609656B0002 for ; Tue, 23 Jun 2020 05:37:19 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E308F11233 for ; Tue, 23 Jun 2020 09:37:18 +0000 (UTC) X-FDA: 76959973356.28.truck16_5c13cbb26e3a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id C229B11227 for ; Tue, 23 Jun 2020 09:37:18 +0000 (UTC) X-HE-Tag: truck16_5c13cbb26e3a X-Filterd-Recvd-Size: 4912 Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Tue, 23 Jun 2020 09:37:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=rr3b1L/FRTesaaOv4/PvWj0LHdOB3M9NfrW+uOEVYWA=; b=YzRmSVnafR71kfHBMtvsTFlor4 R+lp5VMgL0ebzHOh+QEWTBnMhVzxPSRJSHxoDsIzRrvVxe1a7hyOEZkLFNynKT0S4zR6n9Ny4aEXD Xar4W98pYb2i2DeNZZEUUsaOPqH3xOSDCrwgMe01aiW8B8EbuUDcYOxLKwiXLnTfn2j2JYDvjW68F qeVTgtIwKZYkV8POYR+MmUm1uOYFFqlNglQVmBTKco9lFLO2Vt7VcA9opS2xLXGxq+z/3HXWD7Y9C g++uw7TqMk9ZEU4jy1S8OZTepUzIql6kpRloaga4DMwh4j4EUlzV3Zz3xPGj3qZNwYbT3IeWi5gf1 ICi5L0BA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1jnfMi-0007Fm-AT; Tue, 23 Jun 2020 09:37:16 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id D1C5C3003E5; Tue, 23 Jun 2020 11:37:14 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 9947A2370F7C4; Tue, 23 Jun 2020 11:37:14 +0200 (CEST) Date: Tue, 23 Jun 2020 11:37:14 +0200 From: Peter Zijlstra To: Will Deacon Cc: Christoph Hellwig , Andrew Morton , Dexuan Cui , Vitaly Kuznetsov , Catalin Marinas , Jessica Yu , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 2/3] arm64: use PAGE_KERNEL_ROX directly in alloc_insn_page Message-ID: <20200623093714.GE4781@hirez.programming.kicks-ass.net> References: <20200618064307.32739-1-hch@lst.de> <20200618064307.32739-3-hch@lst.de> <20200620191616.bae356186ba3329ade67bbf7@linux-foundation.org> <20200623090505.GA7518@lst.de> <20200623090757.GB3743@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200623090757.GB3743@willie-the-truck> X-Rspamd-Queue-Id: C229B11227 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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: On Tue, Jun 23, 2020 at 10:07:58AM +0100, Will Deacon wrote: > On Tue, Jun 23, 2020 at 11:05:05AM +0200, Christoph Hellwig wrote: > > On Sat, Jun 20, 2020 at 07:16:16PM -0700, Andrew Morton wrote: > > > On Thu, 18 Jun 2020 08:43:06 +0200 Christoph Hellwig wrote: > > > > > > > Use PAGE_KERNEL_ROX directly instead of allocating RWX and setting the > > > > page read-only just after the allocation. > > > > > > > > --- a/arch/arm64/kernel/probes/kprobes.c > > > > +++ b/arch/arm64/kernel/probes/kprobes.c > > > > @@ -120,15 +120,9 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p) > > > > > > > > void *alloc_insn_page(void) > > > > { > > > > - void *page; > > > > - > > > > - page = vmalloc_exec(PAGE_SIZE); > > > > - if (page) { > > > > - set_memory_ro((unsigned long)page, 1); > > > > - set_vm_flush_reset_perms(page); > > > > - } > > > > - > > > > - return page; > > > > + return __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START, VMALLOC_END, > > > > + GFP_KERNEL, PAGE_KERNEL_ROX, VM_FLUSH_RESET_PERMS, > > > > + NUMA_NO_NODE, __func__); > > > > } > > > > > > > > /* arm kprobe: install breakpoint in text */ > > > > > > But why. I think this is just a cleanup, doesn't address any runtime issue? > > > > It doesn't "fix" an issue - it just simplifies and speeds up the code. > > Ok, but I don't understand the PLT comment from Peter in > 20200618092754.GF576905@hirez.programming.kicks-ass.net: > > | I think this has the exact same range issue as the x86 user. But it > | might be less fatal if their PLT magic can cover the full range. > > Peter, please could you elaborate on your concern? I feel like I'm missing > some context. On x86 we can only directly call code in a (signed) 32bit immediate range (2G) and our kernel text and module range are constrained by that. IIRC ARM64 has an even smaller immediate range and needs to play fixup games with trampolines or somesuch (there was an ARM specific name for it that I've misplaced again). Does that machinery cover the entire vmalloc space or are you only able to fix up for a smaller range? Your arch/arm64/kernel/module.c:module_alloc() implementation seems to have an explicit module range different from the full vmalloc range, I'm thinking this is for a reason.