From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932388Ab3LIH3v (ORCPT ); Mon, 9 Dec 2013 02:29:51 -0500 Received: from lgeamrelo02.lge.com ([156.147.1.126]:48830 "EHLO LGEAMRELO02.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750902Ab3LIH3u (ORCPT ); Mon, 9 Dec 2013 02:29:50 -0500 X-AuditID: 9c93017e-b7bb9ae000000ec8-54-52a5716c4039 From: Namhyung Kim To: Masami Hiramatsu Cc: Alexei Starovoitov , Steven Rostedt , Ingo Molnar , Peter Zijlstra , "H. Peter Anvin" , Thomas Gleixner , Tom Zanussi , Jovi Zhangwei , Eric Dumazet , linux-kernel@vger.kernel.org, Linus Torvalds , Andrew Morton , =?utf-8?B?RnLDqWTDqXJpYw==?= Weisbecker , Arnaldo Carvalho de Melo , Tom Zanussi , Pekka Enberg , "David S. Miller" , Arjan van de Ven , Christoph Hellwig , Oleg Nesterov Subject: Re: [RFC PATCH tip 0/5] tracing filters with BPF References: <1386044930-15149-1-git-send-email-ast@plumgrid.com> <20131203091655.GB20179@gmail.com> <20131203103346.65c744e3@gandalf.local.home> <529E81C1.2070208@hitachi.com> Date: Mon, 09 Dec 2013 16:29:48 +0900 In-Reply-To: <529E81C1.2070208@hitachi.com> (Masami Hiramatsu's message of "Wed, 04 Dec 2013 10:13:37 +0900") Message-ID: <877gbemqhf.fsf@sejong.aot.lge.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: AAAAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Masami, On Wed, 04 Dec 2013 10:13:37 +0900, Masami Hiramatsu wrote: > (2013/12/04 3:26), Alexei Starovoitov wrote: >> the only inconvenience so far is to know how parameters are getting >> into registers. >> on x86-64, arg1 is in rdi, arg2 is in rsi,... I want to improve that >> after first step is done. > > Actually, that part is done by the perf-probe and ftrace dynamic events > (kernel/trace/trace_probe.c). I think this generic BPF is good for > re-implementing fetch methods. :) For implementing patch method, it seems that it needs to access to user memory, stack and/or current (task_struct - for utask or vma later) from the BPF VM as well. Isn't it OK from the security perspective? Anyway, I'll take a look at it later if I have time, but I want to get the existing/pending implementation merged first. :) Thanks, Namhyung