On Fri, 11 Apr 2014 14:03:47 +0200
Oleg Nesterov wrote:
> I do remember, I already told you are pedant!
Point taken ;-)
I'll pull your patches into my 3.16 queue.
Thanks!
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 04/10, Steven Rostedt wrote:
>
> On Thu, 10 Apr 2014 21:38:20 +0200
> Oleg Nesterov wrote:
>
> > I _think_ that the kernel thread can only return from "call *%rbx" if
> > it is no longer a kernel thread, iow, do_execve() was called.
>
> Ah right. But only in special cases.
>
> Actually, it
On 04/10, Steven Rostedt wrote:
On Thu, 10 Apr 2014 21:38:20 +0200
Oleg Nesterov o...@redhat.com wrote:
I _think_ that the kernel thread can only return from call *%rbx if
it is no longer a kernel thread, iow, do_execve() was called.
Ah right. But only in special cases.
Actually, it
On Fri, 11 Apr 2014 14:03:47 +0200
Oleg Nesterov o...@redhat.com wrote:
I do remember, I already told you are pedant!
Point taken ;-)
I'll pull your patches into my 3.16 queue.
Thanks!
-- Steve
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Thu, 10 Apr 2014 21:38:20 +0200
Oleg Nesterov wrote:
> I _think_ that the kernel thread can only return from "call *%rbx" if
> it is no longer a kernel thread, iow, do_execve() was called.
Ah right. But only in special cases.
Actually, it only returns if the function in kernel_thread()
On 04/10, Steven Rostedt wrote:
>
> On Thu, 10 Apr 2014 20:14:17 +0200
> Oleg Nesterov wrote:
>
>
> > And I forgot to mention, given that the kernel_thread() callback should
> > call do_exit() itself, then this part of cc3b13c11c567c69a63
> >
> > one case when a kernel thread can reach the
On 04/10, Oleg Nesterov wrote:
>
> On 04/10, Oleg Nesterov wrote:
> >
> > On 04/10, Steven Rostedt wrote:
> > >
> > > Hendrik, we are debating about removing
> > > cc3b13c11c567c69a6356be98d0c03ff11541d5c as it stops
> > > call_usermodehelper tasks from tracing their syscalls.
> > >
> > > If
On Thu, 10 Apr 2014 20:14:17 +0200
Oleg Nesterov wrote:
> And I forgot to mention, given that the kernel_thread() callback should
> call do_exit() itself, then this part of cc3b13c11c567c69a63
>
> one case when a kernel thread can reach the
> usual syscall exit tracing path: when
On 04/10, Oleg Nesterov wrote:
>
> On 04/10, Steven Rostedt wrote:
> >
> > Hendrik, we are debating about removing
> > cc3b13c11c567c69a6356be98d0c03ff11541d5c as it stops
> > call_usermodehelper tasks from tracing their syscalls.
> >
> > If Hendrik has no problems with this, neither do I.
>
> OK.
On 04/10, Steven Rostedt wrote:
>
> On Thu, 10 Apr 2014 16:46:55 +0200
> Oleg Nesterov wrote:
>
> > > void tracepoint_check_syscalls(void)
> > > {
> > > if (!sys_tracepoint_refcount)
> > > return;
> > >
> > > read_lock(_lock);
> > > /* Make sure it wasn't cleared since taking the
On Thu, 10 Apr 2014 16:46:55 +0200
Oleg Nesterov wrote:
> > I mean, the tracepoint is
> > activated usually by humans, and if they enabled it just as a usermode
> > helper is activated, and those are really fast to run, do we even care
> > if it is missed?
>
> A user space task spawned by
On 04/10, Steven Rostedt wrote:
>
> On Thu, 10 Apr 2014 15:38:55 +0200
> Oleg Nesterov wrote:
>
> > > > However, this means that a user-space task spawned by
> > > > call_usermodehelper() won't report the system calls if
> > > > kernel_execve() is called when sys_tracepoint_refcount != 0.
> > >
>
On Thu, 10 Apr 2014 15:38:55 +0200
Oleg Nesterov wrote:
> On 04/10, Steven Rostedt wrote:
> >
> > On Wed, 9 Apr 2014 19:06:16 +0200
> > Oleg Nesterov wrote:
> >
> > > syscall_regfunc() ignores the kernel thread because "it has
> > > no effect", see cc3b13c1 "Don't trace kernel thread syscalls".
On 04/10, Steven Rostedt wrote:
>
> On Wed, 9 Apr 2014 19:06:16 +0200
> Oleg Nesterov wrote:
>
> > syscall_regfunc() ignores the kernel thread because "it has
> > no effect", see cc3b13c1 "Don't trace kernel thread syscalls".
> >
> > However, this means that a user-space task spawned by
> >
On Wed, 9 Apr 2014 19:06:16 +0200
Oleg Nesterov wrote:
> syscall_regfunc() ignores the kernel thread because "it has
> no effect", see cc3b13c1 "Don't trace kernel thread syscalls".
>
> However, this means that a user-space task spawned by
> call_usermodehelper() won't report the system calls
On Wed, 9 Apr 2014 19:06:16 +0200
Oleg Nesterov o...@redhat.com wrote:
syscall_regfunc() ignores the kernel thread because it has
no effect, see cc3b13c1 Don't trace kernel thread syscalls.
However, this means that a user-space task spawned by
call_usermodehelper() won't report the system
On 04/10, Steven Rostedt wrote:
On Wed, 9 Apr 2014 19:06:16 +0200
Oleg Nesterov o...@redhat.com wrote:
syscall_regfunc() ignores the kernel thread because it has
no effect, see cc3b13c1 Don't trace kernel thread syscalls.
However, this means that a user-space task spawned by
On Thu, 10 Apr 2014 15:38:55 +0200
Oleg Nesterov o...@redhat.com wrote:
On 04/10, Steven Rostedt wrote:
On Wed, 9 Apr 2014 19:06:16 +0200
Oleg Nesterov o...@redhat.com wrote:
syscall_regfunc() ignores the kernel thread because it has
no effect, see cc3b13c1 Don't trace kernel
On 04/10, Steven Rostedt wrote:
On Thu, 10 Apr 2014 15:38:55 +0200
Oleg Nesterov o...@redhat.com wrote:
However, this means that a user-space task spawned by
call_usermodehelper() won't report the system calls if
kernel_execve() is called when sys_tracepoint_refcount != 0.
On Thu, 10 Apr 2014 16:46:55 +0200
Oleg Nesterov o...@redhat.com wrote:
I mean, the tracepoint is
activated usually by humans, and if they enabled it just as a usermode
helper is activated, and those are really fast to run, do we even care
if it is missed?
A user space task spawned by
On 04/10, Steven Rostedt wrote:
On Thu, 10 Apr 2014 16:46:55 +0200
Oleg Nesterov o...@redhat.com wrote:
void tracepoint_check_syscalls(void)
{
if (!sys_tracepoint_refcount)
return;
read_lock(tasklist_lock);
/* Make sure it wasn't cleared since taking the
On 04/10, Oleg Nesterov wrote:
On 04/10, Steven Rostedt wrote:
Hendrik, we are debating about removing
cc3b13c11c567c69a6356be98d0c03ff11541d5c as it stops
call_usermodehelper tasks from tracing their syscalls.
If Hendrik has no problems with this, neither do I.
OK.
cc3b13c11c567
On Thu, 10 Apr 2014 20:14:17 +0200
Oleg Nesterov o...@redhat.com wrote:
And I forgot to mention, given that the kernel_thread() callback should
call do_exit() itself, then this part of cc3b13c11c567c69a63
one case when a kernel thread can reach the
usual syscall exit tracing
On 04/10, Oleg Nesterov wrote:
On 04/10, Oleg Nesterov wrote:
On 04/10, Steven Rostedt wrote:
Hendrik, we are debating about removing
cc3b13c11c567c69a6356be98d0c03ff11541d5c as it stops
call_usermodehelper tasks from tracing their syscalls.
If Hendrik has no problems with
On 04/10, Steven Rostedt wrote:
On Thu, 10 Apr 2014 20:14:17 +0200
Oleg Nesterov o...@redhat.com wrote:
And I forgot to mention, given that the kernel_thread() callback should
call do_exit() itself, then this part of cc3b13c11c567c69a63
one case when a kernel thread can reach
On Thu, 10 Apr 2014 21:38:20 +0200
Oleg Nesterov o...@redhat.com wrote:
I _think_ that the kernel thread can only return from call *%rbx if
it is no longer a kernel thread, iow, do_execve() was called.
Ah right. But only in special cases.
Actually, it only returns if the function in
syscall_regfunc() ignores the kernel thread because "it has
no effect", see cc3b13c1 "Don't trace kernel thread syscalls".
However, this means that a user-space task spawned by
call_usermodehelper() won't report the system calls if
kernel_execve() is called when sys_tracepoint_refcount != 0.
syscall_regfunc() ignores the kernel thread because it has
no effect, see cc3b13c1 Don't trace kernel thread syscalls.
However, this means that a user-space task spawned by
call_usermodehelper() won't report the system calls if
kernel_execve() is called when sys_tracepoint_refcount != 0.
Remove
28 matches
Mail list logo
