From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68738 invoked by alias); 12 Apr 2017 06:42:32 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 67579 invoked by uid 89); 12 Apr 2017 06:42:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*Ad:U*michael, Hx-languages-length:1558, tip, tracer X-HELO: mail-wm0-f68.google.com Received: from mail-wm0-f68.google.com (HELO mail-wm0-f68.google.com) (74.125.82.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Apr 2017 06:42:29 +0000 Received: by mail-wm0-f68.google.com with SMTP id x75so4360749wma.1 for ; Tue, 11 Apr 2017 23:42:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=Ktdh1chn1VmX+srfYukfBDb/LlQEW+0Mz037VFlm1CE=; b=RxGt8kCD+S0SD5wWdtUnCg3kAEVFztFuvf2J1Un+jYIAZImt5NLfT/lFHBskQsfGOV OEGzsriafHhGJ9ORnbOeuxJvb0UACirMxk64PTyMnq9aWpxvcZgwMcr8wnOkoGaZ/hkS 4mjBmwWe4/Tvrx+Ryyq/SNLs9iVvpi9nxS52JXHRWciyYXz4qerBRmJTMzu08ebrYFTB kURnlKZoT8XUcofc01ivan8qVohhhux2bpuQDskBIj/VBs2X3XdNOHhO4T1lR/karnyY GKyu7vyiEox1ZemqrNXbztQc7gjMJ2kMkmFgl2XWBL41Jb/1RMEg7x5R3XL/SnUZ65Ep OzvA== X-Gm-Message-State: AN3rC/7Wy9sIxIQ3Zhl7CVC68JWifkUIVU8csLzuR/gy+oZx9T7BjRaqm2qp2iS+suZQQA== X-Received: by 10.28.153.4 with SMTP id b4mr1183773wme.58.1491979348954; Tue, 11 Apr 2017 23:42:28 -0700 (PDT) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id 32sm24395253wrq.25.2017.04.11.23.42.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Apr 2017 23:42:28 -0700 (PDT) Date: Wed, 12 Apr 2017 06:42:00 -0000 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) X-SW-Source: 2017-q2/txt/msg00018.txt.bz2 * 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