Messages in this thread | | | Date | Thu, 10 Apr 2014 11:08:48 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH RESEND 2/2] tracing: syscall_regfunc() should not skip kernel threads |
| |
On Thu, 10 Apr 2014 16:46:55 +0200 Oleg Nesterov <oleg@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 call_usermodehelper() can do everything, it > can run forever.
Sounds nasty ;-)
> > > Now, if tracing is on and we need to set the flag, that should take the > > task list lock to make sure that we don't miss clearing it. Missing the > > set isn't a big deal, but missing the clearing of the flag is. > > > > void tracepoint_check_syscalls(void) > > { > > if (!sys_tracepoint_refcount) > > return; > > > > read_lock(&tasklist_lock); > > /* Make sure it wasn't cleared since taking the lock */ > > if (sys_tracepoint_refcount) > > set_tsk_thread_flag(current, TIF_SYSCALL_TRACEPOINT); > > read_unlock(&tasklist_lock); > > } > > And how this can help to avoid the race? We need write_lock_irq().
But you chopped off the last part. Where I replaced tasklist_lock with a tracepoint specific lock that would synchronize sys_tracepoint_refcount with the setting of the flags.
> > Perhaps I missed something... and I simply do not understand why do you > want to do this.
Because I'm being an ass ;-)
The real reason I'm doing this debate is more to find out exactly what the problems are. A learning exercise if you will. I just don't want to add a regression, as Hendrik (which I just Cc'd) added the commit for a reason. Perhaps you are correct that we should just go back to the way things were.
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.
-- Steve
| |