Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933406AbdC3Gxq (ORCPT ); Thu, 30 Mar 2017 02:53:46 -0400 Received: from mail-wr0-f195.google.com ([209.85.128.195]:33118 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933095AbdC3Gxm (ORCPT ); Thu, 30 Mar 2017 02:53:42 -0400 Date: Thu, 30 Mar 2017 08:53:32 +0200 From: Ingo Molnar To: Masami Hiramatsu Cc: Steven Rostedt , Ingo Molnar , Alban Crequy , Alban Crequy , Alexei Starovoitov , Jonathan Corbet , Arnaldo Carvalho de Melo , Omar Sandoval , linux-doc@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, iago@kinvolk.io, michael@kinvolk.io, Dorau Lukasz , systemtap@sourceware.org Subject: Re: [RFC PATCH tip/master 2/3] kprobes: Allocate kretprobe instance if its free list is empty Message-ID: <20170330065332.GA30148@gmail.com> References: <149076484118.24574.7083269903420611708.stgit@devbox> <149076498222.24574.679546540523044200.stgit@devbox> <20170329063005.GA12220@gmail.com> <20170329172510.e012406497fd38a54d5069b3@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170329172510.e012406497fd38a54d5069b3@kernel.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1213 Lines: 30 * Masami Hiramatsu wrote: > > So this is something I missed while the original code was merged, but the concept > > looks a bit weird: why do we do any "allocation" while a handler is executing? > > > > That's fundamentally fragile. What's the maximum number of parallel > > 'kretprobe_instance' required per kretprobe - one per CPU? > > It depends on the place where we put the probe. If the probed function will be > blocked (yield to other tasks), then we need a same number of threads on > the system which can invoke the function. So, ultimately, it is same > as function_graph tracer, we need it for each thread. So then put it into task_struct (assuming there's no kretprobe-inside-kretprobe nesting allowed). There's just no way in hell we should be calling any complex kernel function from kernel probes! I mean, think about it, a kretprobe can be installed in a lot of places, and now we want to call get_free_pages() from it?? This would add a massive amount of fragility. Instrumentation must be _simple_, every patch that adds more complexity to the most fundamental code path of it should raise a red flag ... So let's make this more robust, ok? Thanks, Ingo