Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753049AbdDLGmd (ORCPT ); Wed, 12 Apr 2017 02:42:33 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33668 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751255AbdDLGma (ORCPT ); Wed, 12 Apr 2017 02:42:30 -0400 Date: Wed, 12 Apr 2017 08:42:26 +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: <20170412064226.GA7737@gmail.com> References: <149076484118.24574.7083269903420611708.stgit@devbox> <149076498222.24574.679546540523044200.stgit@devbox> <20170329063005.GA12220@gmail.com> <20170329172510.e012406497fd38a54d5069b3@kernel.org> <20170330065332.GA30148@gmail.com> <20170330220134.448b65b9102edcf8ba1a2c81@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170330220134.448b65b9102edcf8ba1a2c81@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: 1475 Lines: 38 * Masami Hiramatsu wrote: > On Thu, 30 Mar 2017 08:53:32 +0200 > Ingo Molnar wrote: > > > > > * 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). > > No, that is possible to put several kretprobes on same thread, e.g. > the func1() is called from func2(), user can put kretprobes for each > function at same time. > So the possible solution is to allocate new return-stack for each task_struct, > and that is what the function-graph tracer did. > > Anyway, I'm considering to integrate kretprobe_instance with the ret_stack. > It will increase memory usage for kretprobes, but can provide safer way > to allocate kretprobe_instance. Ok, that sounds good to me. Thanks, Ingo