lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 4 Nov 2017 12:05:20 +0100 From: Greg KH <gregkh@...uxfoundation.org> To: KY Srinivasan <kys@...rosoft.com> Cc: Steven Rostedt <rostedt@...dmis.org>, "olaf@...fle.de" <olaf@...fle.de>, Stephen Hemminger <sthemmin@...rosoft.com>, "jasowang@...hat.com" <jasowang@...hat.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "apw@...onical.com" <apw@...onical.com>, "marcelo.cerri@...onical.com" <marcelo.cerri@...onical.com>, "devel@...uxdriverproject.org" <devel@...uxdriverproject.org>, Vitaly Kuznetsov <vkuznets@...hat.com>, "leann.ogasawara@...onical.com" <leann.ogasawara@...onical.com> Subject: Re: [PATCH 10/17] hyper-v: trace vmbus_open() On Wed, Nov 01, 2017 at 05:43:08PM +0000, KY Srinivasan wrote: > > > > -----Original Message----- > > From: devel [mailto:driverdev-devel-bounces@...uxdriverproject.org] On > > Behalf Of Steven Rostedt > > Sent: Tuesday, October 31, 2017 6:10 AM > > To: Greg KH <gregkh@...uxfoundation.org> > > Cc: olaf@...fle.de; Stephen Hemminger <sthemmin@...rosoft.com>; > > jasowang@...hat.com; linux-kernel@...r.kernel.org; apw@...onical.com; > > marcelo.cerri@...onical.com; devel@...uxdriverproject.org; Vitaly > > Kuznetsov <vkuznets@...hat.com>; leann.ogasawara@...onical.com > > Subject: Re: [PATCH 10/17] hyper-v: trace vmbus_open() > > > > On Tue, 31 Oct 2017 13:48:00 +0100 > > Greg KH <gregkh@...uxfoundation.org> wrote: > > > > > > I don't see how that information can be extracted easily without a > > > > tracepoint here. Am I missing something? > > > > > > Wasn't one of the outcomes of the conference last week the fact that for > > > ftrace + ebpf we could get access to the structures of the function > > > parameters? Or that work would soon be showing up? > > > > I told Linus that I'll start building an infrastructure on function > > tracing to see what we can do. But it may be very limited in features. > > I don't believe eBPF can follow arbitrary data structure pointers > > without helper functions. Which doesn't exist for this type of code yet. > > > > > > > > It just feels "wrong" to add a tracepoint for a function call, like it > > > is a duplication of work/functionality we already have. > > > > We don't already have it. We may have something in a year (or two) that > > may be able to get all the data that is requested here. But it's going > > to take lots of RFC patch sets and brain storming to come up with > > something that everyone is satisfied with. > > > > In other words, the functionality is currently in vaporware state. > > Greg, > > The added memory overhead is very minimal, and the added tracing support is extremely useful for > our debugging. If you don't mind, I would like to have this tracing support. Ok, it's your subsystem, you get to handle the long-term maintenance of these :) Now merged, greg k-h
Powered by blists - more mailing lists