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=-6.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, 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 5E8ACC28B49 for ; Fri, 28 Aug 2020 01:57:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3104320848 for ; Fri, 28 Aug 2020 01:57:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598579869; bh=ytVYmdvTxAHSvpNi2RcVC8TEBHrhZKe/ZTew0OdUFkg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=exCgvu23WoyoWKEQs1g2hH5b8r/JOHpmoHRj6Qc6DgGr2LhiKKPlOe0G4jp4s+qjB NRcC0OHu3Z1YCQzgDif61Vr/CZ/zOyrLlYlM/8YbjhYhqZyF2ObPVjeRgl0Kev0npm foDbUJAzTTA8CJNmJ91bOtgmeDCsQPlZrBlgnkdU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728365AbgH1B5Y (ORCPT ); Thu, 27 Aug 2020 21:57:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:36464 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728338AbgH1B5U (ORCPT ); Thu, 27 Aug 2020 21:57:20 -0400 Received: from devnote2 (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 40E602080C; Fri, 28 Aug 2020 01:57:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1598579840; bh=ytVYmdvTxAHSvpNi2RcVC8TEBHrhZKe/ZTew0OdUFkg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=n1Ug5cjFKvK7LDWSaWQXnOwQtS4KmW086f5qCkSAxdNbnQDxNtBCQeh3u0gd4Amc+ CUwWt7TRQR8rg+BpnvA9u0wFBEUn/MsJKg/KeUyjQLJxyRNxNCbhce6vL/LoWFUHO3 2hIJRZeNqAsqoo93U3qbnLy96JyVfjPvNiqnhdSY= Date: Fri, 28 Aug 2020 10:57:14 +0900 From: Masami Hiramatsu To: Masami Hiramatsu Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Eddy Wu , x86@kernel.org, "David S . Miller" , Steven Rostedt , Ingo Molnar , "Naveen N . Rao" , Anil S Keshavamurthy , linux-arch@vger.kernel.org, guoren@kernel.org Subject: Re: [PATCH v3 01/16] kprobes: Add generic kretprobe trampoline handler Message-Id: <20200828105714.b499777a12e5cd5d11855f8b@kernel.org> In-Reply-To: <159854632381.736475.17150452390088286224.stgit@devnote2> References: <159854631442.736475.5062989489155389472.stgit@devnote2> <159854632381.736475.17150452390088286224.stgit@devnote2> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Fri, 28 Aug 2020 01:38:44 +0900 Masami Hiramatsu wrote: > +unsigned long __kretprobe_trampoline_handler(struct pt_regs *regs, > + unsigned long trampoline_address, > + void *frame_pointer) > +{ > + struct kretprobe_instance *ri = NULL; > + struct hlist_head *head, empty_rp; > + struct hlist_node *tmp; > + unsigned long flags, orig_ret_address = 0; > + kprobe_opcode_t *correct_ret_addr = NULL; > + bool skipped = false; > + > + INIT_HLIST_HEAD(&empty_rp); > + kretprobe_hash_lock(current, &head, &flags); > + > + /* > + * It is possible to have multiple instances associated with a given > + * task either because multiple functions in the call path have > + * return probes installed on them, and/or more than one > + * return probe was registered for a target function. > + * > + * We can handle this because: > + * - instances are always pushed into the head of the list > + * - when multiple return probes are registered for the same > + * function, the (chronologically) first instance's ret_addr > + * will be the real return address, and all the rest will > + * point to kretprobe_trampoline. > + */ > + hlist_for_each_entry(ri, head, hlist) { > + if (ri->task != current) > + /* another task is sharing our hash bucket */ > + continue; > + /* > + * Return probes must be pushed on this hash list correct > + * order (same as return order) so that it can be popped > + * correctly. However, if we find it is pushed it incorrect > + * order, this means we find a function which should not be > + * probed, because the wrong order entry is pushed on the > + * path of processing other kretprobe itself. > + */ > + if (ri->fp != frame_pointer) { > + if (!skipped) > + pr_warn("kretprobe is stacked incorrectly. Trying to fixup.\n"); > + skipped = true; > + continue; > + } > + > + orig_ret_address = (unsigned long)ri->ret_addr; > + if (skipped) > + pr_warn("%ps must be blacklisted because of incorrect kretprobe order\n", > + ri->rp->kp.addr); > + > + if (orig_ret_address != trampoline_address) > + /* > + * This is the real return address. Any other > + * instances associated with this task are for > + * other calls deeper on the call stack > + */ > + break; > + } > + > + kretprobe_assert(ri, orig_ret_address, trampoline_address); > + > + correct_ret_addr = ri->ret_addr; Oops, here is an insane code... why we have orig_ret_address *and* correct_ret_addr? I'll clean this up. Thanks, -- Masami Hiramatsu