tracing: add compat syscall support v3
in [Kernel]
|
Prev: [rfc] Describe events in a structured way via sysfs
Next: perf, trace: Use per-tracepoint-per-cpu hlist to track events
From: Ian Munsie on 21 May 2010 05:50 Hi Jason, I'm currently in the process of implementing syscall tracepoints for PowerPC, and a considerable amount of my work is going to end up requiring these patches of yours. I've reviewed and tested your patches (and spent a good chunk of time rebasing them on top of tip/tracing/core) and they all seem pretty good. I *particularly* like the way in which they prevent ftrace syscalls from reporting that sys_swapoff was constantly firing on x86_64 kernels with a 32bit userspace ;) Anyway, I'm just wondering if you have an ETA for the v4 patchset to address the remaining issues that Frederic raised so that they can be merged. Cheers, -Ian Excerpts from Jason Baron's message of Wed Mar 17 04:46:08 +1100 2010: > Hi, > > Re-post to add infrastructure for compat syscall event tracing support. This > patch series also adds x86_64 arch specific support as an example consumer > of the new infrastructure. > > Arches can request compat syscall tracing by setting: > __HAVE_ARCH_FTRACE_COMPAT_SYSCALLS, if CONFIG_COMPAT and CONFIG_FTRACE_SYSCALLS > are set. Arches then need to implement the following interfaces: > > 1) int is_compat_task(void); > - most arches seem to have this already > 2) unsigned long arch_compat_syscall_addr(int nr); > - returns a pointer to the compat syscall entry corresponding to syscall 'nr' > 3) int NR_syscalls_compat; > - number of entries in the compat syscall table. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jason Baron on 21 May 2010 09:30 On Fri, May 21, 2010 at 07:40:21PM +1000, Ian Munsie wrote: > Hi Jason, > > I'm currently in the process of implementing syscall tracepoints for > PowerPC, and a considerable amount of my work is going to end up > requiring these patches of yours. I've reviewed and tested your patches > (and spent a good chunk of time rebasing them on top of > tip/tracing/core) and they all seem pretty good. > > I *particularly* like the way in which they prevent ftrace syscalls from > reporting that sys_swapoff was constantly firing on x86_64 kernels with > a 32bit userspace ;) > > Anyway, I'm just wondering if you have an ETA for the v4 patchset to > address the remaining issues that Frederic raised so that they can be > merged. > > Cheers, > -Ian > hi Ian, I think the main issue left was that I am using the same meta data for both the 32-bit and 64-bit table entries, when they reference the same syscall. for example, for x86 both the compat and underlying 64-bit kernel reference 'sys_rename'. Thus, i am pointing both perf events at the same meta data. Frederic was saying they need to be separate. I'm not sure i completely understand why, since the 32-bit are just sign extended to 64-bit in this case. Frederic, perhaps, you can explain this a bit more for me? thanks, -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Frederic Weisbecker on 21 May 2010 09:40 On Fri, May 21, 2010 at 09:24:07AM -0400, Jason Baron wrote: > On Fri, May 21, 2010 at 07:40:21PM +1000, Ian Munsie wrote: > > Hi Jason, > > > > I'm currently in the process of implementing syscall tracepoints for > > PowerPC, and a considerable amount of my work is going to end up > > requiring these patches of yours. I've reviewed and tested your patches > > (and spent a good chunk of time rebasing them on top of > > tip/tracing/core) and they all seem pretty good. > > > > I *particularly* like the way in which they prevent ftrace syscalls from > > reporting that sys_swapoff was constantly firing on x86_64 kernels with > > a 32bit userspace ;) > > > > Anyway, I'm just wondering if you have an ETA for the v4 patchset to > > address the remaining issues that Frederic raised so that they can be > > merged. > > > > Cheers, > > -Ian > > > > hi Ian, > > I think the main issue left was that I am using the same meta data for > both the 32-bit and 64-bit table entries, when they reference the same > syscall. for example, for x86 both the compat and underlying 64-bit > kernel reference 'sys_rename'. Thus, i am pointing both perf events at > the same meta data. Frederic was saying they need to be separate. I'm > not sure i completely understand why, since the 32-bit are just sign > extended to 64-bit in this case. Frederic, perhaps, you can explain this > a bit more for me? > > thanks, > > -Jason If they are pointing to the same function with the same parameters, then yeah it's fine. I think I worried about two different handlers that don't have the exact same parameters (one having compat things, and the other having not). But now that I think about it that's probably not what you did. I'll give another shot to this patchset then, as I've probably confused something, I just need to wait a bit for the giant patchset from Steve on trace events to be applied, before applying this set. Should happen soon. Will look at this next week. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ian Munsie on 17 Jun 2010 03:40 Excerpts from Jason Baron's message of Fri May 21 23:24:07 +1000 2010: > On Fri, May 21, 2010 at 07:40:21PM +1000, Ian Munsie wrote: > > Hi Jason, > > > > I'm currently in the process of implementing syscall tracepoints for > > PowerPC, and a considerable amount of my work is going to end up > > requiring these patches of yours. I've reviewed and tested your patches > > (and spent a good chunk of time rebasing them on top of > > tip/tracing/core) and they all seem pretty good. > > > > I *particularly* like the way in which they prevent ftrace syscalls from > > reporting that sys_swapoff was constantly firing on x86_64 kernels with > > a 32bit userspace ;) > > > > Anyway, I'm just wondering if you have an ETA for the v4 patchset to > > address the remaining issues that Frederic raised so that they can be > > merged. > > > > Cheers, > > -Ian > > > > hi Ian, > > I think the main issue left was that I am using the same meta data for > both the 32-bit and 64-bit table entries, when they reference the same > syscall. for example, for x86 both the compat and underlying 64-bit > kernel reference 'sys_rename'. Thus, i am pointing both perf events at > the same meta data. Frederic was saying they need to be separate. I'm > not sure i completely understand why, since the 32-bit are just sign > extended to 64-bit in this case. Frederic, perhaps, you can explain this > a bit more for me? > > thanks, > > -Jason Hi Jason, I'm currently cleaning up my patch series for ftrace syscalls on PowerPC and want to release it soon. It's probably easiest for me if I release your compat syscall support v3 patches as part of the series. You'd still be marked as the author of those commits - the only changes I have made to them was rebasing them against the current tip tree and resolving the conflicts that I came across. Is that OK with you? Otherwise I can wait until you put out the v4 patches then rebase mine on top of those. Cheers, -Ian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Frederic Weisbecker on 17 Jun 2010 03:50
On Thu, Jun 17, 2010 at 05:39:07PM +1000, Ian Munsie wrote: > Excerpts from Jason Baron's message of Fri May 21 23:24:07 +1000 2010: > > On Fri, May 21, 2010 at 07:40:21PM +1000, Ian Munsie wrote: > > > Hi Jason, > > > > > > I'm currently in the process of implementing syscall tracepoints for > > > PowerPC, and a considerable amount of my work is going to end up > > > requiring these patches of yours. I've reviewed and tested your patches > > > (and spent a good chunk of time rebasing them on top of > > > tip/tracing/core) and they all seem pretty good. > > > > > > I *particularly* like the way in which they prevent ftrace syscalls from > > > reporting that sys_swapoff was constantly firing on x86_64 kernels with > > > a 32bit userspace ;) > > > > > > Anyway, I'm just wondering if you have an ETA for the v4 patchset to > > > address the remaining issues that Frederic raised so that they can be > > > merged. > > > > > > Cheers, > > > -Ian > > > > > > > hi Ian, > > > > I think the main issue left was that I am using the same meta data for > > both the 32-bit and 64-bit table entries, when they reference the same > > syscall. for example, for x86 both the compat and underlying 64-bit > > kernel reference 'sys_rename'. Thus, i am pointing both perf events at > > the same meta data. Frederic was saying they need to be separate. I'm > > not sure i completely understand why, since the 32-bit are just sign > > extended to 64-bit in this case. Frederic, perhaps, you can explain this > > a bit more for me? > > > > thanks, > > > > -Jason > > Hi Jason, > > I'm currently cleaning up my patch series for ftrace syscalls on PowerPC > and want to release it soon. > > It's probably easiest for me if I release your compat syscall support v3 > patches as part of the series. You'd still be marked as the author of > those commits - the only changes I have made to them was rebasing them > against the current tip tree and resolving the conflicts that I came > across. Perfect! I was about to ask Jason to rebase his patchset against latest -tip. If you send this set, please also add your own Signed-off-by. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |