[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.0908261042250.23885@gandalf.stny.rr.com>
Date: Wed, 26 Aug 2009 10:43:01 -0400 (EDT)
From: Steven Rostedt <rostedt@...dmis.org>
To: Frederic Weisbecker <fweisbec@...il.com>
cc: Heiko Carstens <heiko.carstens@...ibm.com>,
Hendrik Brueckner <brueckner@...ux.vnet.ibm.com>,
Jason Baron <jbaron@...hat.com>, linux-kernel@...r.kernel.org,
mingo@...e.hu, laijs@...fujitsu.com, peterz@...radead.org,
mathieu.desnoyers@...ymtl.ca, jiayingz@...gle.com,
mbligh@...gle.com, lizf@...fujitsu.com,
Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [PATCH 08/12] add trace events for each syscall entry/exit
On Wed, 26 Aug 2009, Frederic Weisbecker wrote:
> >
> > Oh yes, you are right. kernel threads created with kernel_thread()
> > have t->mm != NULL if the forking process has an mm too.
> >
> > There are very few callsites left which still use kernel_thread().
> > (the last one in s390 driver code will be gone after the next
> > merge window).
> >
> > As far as I can there are only four callsites left
> > (excluding staging): jffs2 and three in net/bluetooth/*
>
>
> In that case, I'd suggest to pick the patch that checks for
> kernel threads while setting the TIF_FLAGS.
>
> The check for invalid syscall numbers in another patch should be
> sufficient to not crash.
>
> We might have rare inaccurate result because of the remaining
> buggy callsites but instead of working around on it, these
> should be fixed.
Well, do these (buggy threads) call syscalls?
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists