Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp566040ybg; Tue, 28 Jul 2020 12:59:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxL5LCv3xr8bd7UHf9TxjKvDwCTj4azYeF+6Tl53WVA7RyCvZLDoxqIAzD2CVogbN4RLEyJ X-Received: by 2002:a17:906:a94b:: with SMTP id hh11mr11648740ejb.104.1595966396175; Tue, 28 Jul 2020 12:59:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595966396; cv=none; d=google.com; s=arc-20160816; b=XAg3f9WWHZgDXD0wRJkOy86Uye7G4nKF3+d7niwWOQy1rFSlthnTFaStXpASrfDRPi C3cLPN6//DF/6Nvf3814xWtqEGr9su+HvqS+TokOGEIJyzIMJ9KVg+qVb+ZFPKG3wFuJ z1PUggPgttSUHl532PJtyqTGi81Ndd+7gfHL7SvPdRnD5U3h+iv0PFRpCHPPzEqVCts+ N8005V7regEiVg3WgqsNq038DWc5hWicyhNSEMljLugBdjVSPu90Q1sdEeNEFNYFd2i2 3TKWyGI+9AxdmmPfwpiEUP0kO6YyhybGyipXvPqsrfBJHBzrRQ1lq9pZAfQ+pe62Nx7V Z97A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=b2CbLtGnTxp+CFJflIVSdNd2fI70dlPU12fzCdJqXok=; b=CD/1DPVBZi0UbRG9RS3xAisLlX7o3WwbPO2Jb0ykOYSdMvHxxxz9ygEcAcv+bT93gv HtxPxamL3NXuR607r2kg7030UrJ3QXBHuC/YmxjIX8ryQ79kFuVj+DcG0qW/h/DpFWPl W1ZVWx39zWGSRosZ6WSu5ZSnnjRQw8eae2XDJnGCHE0Dzx4unR9KeDtFjKxI+X2ZmE/T ITXeU9BzuS2ERDJ4KY6u/b9a9CMZeEEXlrAizRGrYgCs1rg0QjggGmM2JDJ0GarUu1xY AQjxqjt8JmA+PNFL0YDqAYWmtdWqnnoH1V+1z5r1o63+YV4+VH3d3BbmhdbqkfjSOFat IYQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=RQFyeY9o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c1si6437622eds.87.2020.07.28.12.59.08; Tue, 28 Jul 2020 12:59:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=RQFyeY9o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732096AbgG1RvU (ORCPT + 99 others); Tue, 28 Jul 2020 13:51:20 -0400 Received: from mail.kernel.org ([198.145.29.99]:54804 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732083AbgG1RvU (ORCPT ); Tue, 28 Jul 2020 13:51:20 -0400 Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 232102083B for ; Tue, 28 Jul 2020 17:51:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595958680; bh=6jcL8Ywxu0wIDS2/EBltw8otMDCJosWWa2C5+dsi7N0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=RQFyeY9oZhZ7LptyowMlRda8iRBLxGZb/JQd4LXHzTq6cXGnqdVU9FjXqH970bQ5l 0HTDrqL4n7m2JmgNPlbtl+r+O4A1pmo2cOPEmviaUBTrjdrcwOe/eboIUqfmRJ/7hO LRp7le7a82T2WmIQjVBNwV/ONSaUTl86An3vXANI= Received: by mail-ot1-f41.google.com with SMTP id w17so15521591otl.4 for ; Tue, 28 Jul 2020 10:51:20 -0700 (PDT) X-Gm-Message-State: AOAM530NOi/OYNuvAD+ntG4XfOBS+Dwvz2j+r8b+vLr0VZOyn7JICOFk iUn0TBsfcVxQhYMqQf59tf5ltHEyGteyCmrKSHY= X-Received: by 2002:a05:6830:1094:: with SMTP id y20mr13388085oto.90.1595958679426; Tue, 28 Jul 2020 10:51:19 -0700 (PDT) MIME-Version: 1.0 References: <20200724050553.1724168-1-jarkko.sakkinen@linux.intel.com> <20200724050553.1724168-6-jarkko.sakkinen@linux.intel.com> <20200724092746.GD517988@gmail.com> <20200725031648.GG17052@linux.intel.com> <20200726081408.GB2927915@kernel.org> <20200728171715.0800093e2226e3d72b04a3ae@kernel.org> <20200728223545.ce4ff78cac73b571a27bb357@kernel.org> In-Reply-To: <20200728223545.ce4ff78cac73b571a27bb357@kernel.org> From: Ard Biesheuvel Date: Tue, 28 Jul 2020 20:51:08 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 5/6] kprobes: Use text_alloc() and text_free() To: Masami Hiramatsu Cc: Mike Rapoport , Jarkko Sakkinen , Ingo Molnar , Linux Kernel Mailing List , linux-mm@kvack.org, Andi Kleen , Peter Zijlstra , "Naveen N. Rao" , Anil S Keshavamurthy , "David S. Miller" , Jessica Yu Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 28 Jul 2020 at 16:35, Masami Hiramatsu wrote: > > On Tue, 28 Jul 2020 13:56:43 +0300 > Ard Biesheuvel wrote: > > > On Tue, 28 Jul 2020 at 11:17, Masami Hiramatsu wrote: > > > > Masami or Peter should correct me if I am wrong, but it seems to me > > > > that the way kprobes uses these pages does not require them to be in > > > > relative branching range of the core kernel on any architecture, given > > > > that they are populated with individual instruction opcodes that are > > > > executed in single step mode, and relative branches are emulated (when > > > > needed) > > > > > > Actually, x86 and arm has the "relative branching range" requirements > > > for the jump optimized kprobes. For the other architectures, I think > > > we don't need it. Only executable text buffer is needed. > > > > > > > Thanks for the explanation. Today, arm64 uses the definition below. > > > > void *alloc_insn_page(void) > > { > > return __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START, VMALLOC_END, > > GFP_KERNEL, PAGE_KERNEL_ROX, VM_FLUSH_RESET_PERMS, > > NUMA_NO_NODE, __builtin_return_address(0)); > > } > > > > Do you think we could use that as the generic implementation if we use > > MODULES_START/_END as the allocation window? > > Yes, but for the generic implementation, we don't need to consider the > relative branching range since we can override it for x86 and arm. > (and that will be almost same as module_alloc() default code) Indeed. So having kprobes specific macros that default to VMALLOC_START/END but can be overridden would be sufficient. > BTW, is PAGE_KERNEL_ROX flag available generically? > Turns out that it is not :-( > Thank you, > -- > Masami Hiramatsu