[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1305587432.2915.57.camel@work-vm>
Date: Mon, 16 May 2011 16:10:32 -0700
From: John Stultz <john.stultz@...aro.org>
To: Jiri Slaby <jirislaby@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>, "Ted Ts'o" <tytso@....edu>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
David Rientjes <rientjes@...gle.com>,
Dave Hansen <dave@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org
Subject: Re: [PATCH 2/3] printk: Add %ptc to safely print a task's comm
On Mon, 2011-05-16 at 23:54 +0200, Jiri Slaby wrote:
> On 05/16/2011 11:19 PM, John Stultz wrote:
> > Accessing task->comm requires proper locking. However in the past
> > access to current->comm could be done without locking. This
> > is no longer the case, so all comm access needs to be done
> > while holding the comm_lock.
> >
> > In my attempt to clean up unprotected comm access, I've noticed
> > most comm access is done for printk output. To simplify correct
> > locking in these cases, I've introduced a new %ptc format,
> > which will print the corresponding task's comm.
> >
> > Example use:
> > printk("%ptc: unaligned epc - sending SIGBUS.\n", current);
> >
> > CC: Ted Ts'o <tytso@....edu>
> > CC: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> > CC: David Rientjes <rientjes@...gle.com>
> > CC: Dave Hansen <dave@...ux.vnet.ibm.com>
> > CC: Andrew Morton <akpm@...ux-foundation.org>
> > CC: linux-mm@...ck.org
> > Signed-off-by: John Stultz <john.stultz@...aro.org>
> > ---
> > lib/vsprintf.c | 24 ++++++++++++++++++++++++
> > 1 files changed, 24 insertions(+), 0 deletions(-)
> >
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > index bc0ac6b..b7a9953 100644
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -797,6 +797,23 @@ char *uuid_string(char *buf, char *end, const u8 *addr,
> > return string(buf, end, uuid, spec);
> > }
> >
> > +static noinline_for_stack
>
> Actually, why noinline? Did your previous version have there some
> TASK_COMM_LEN buffer or anything on stack which is not there anymore?
No, I was just following how almost all of the pointer() called
functions were declared.
But with two pointers and a long, I add more then ip6_string() has on
the stack, which uses the same notation.
But I can drop that bit if there's really no need for it.
thanks
-john
--
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