[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1305076561.2939.72.camel@work-vm>
Date: Tue, 10 May 2011 18:16:01 -0700
From: john stultz <johnstul@...ibm.com>
To: Joe Perches <joe@...ches.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 Tue, 2011-05-10 at 18:10 -0700, John Stultz wrote:
> On Tue, 2011-05-10 at 17:51 -0700, Joe Perches wrote:
> > Could misuse of %ptc (not using current) cause system lockup?
>
> It very well could. Although I don't see other %p options tring to
> handle invalid pointers. Any suggestions on how to best handle this?
And just to clarify on this point, I'm responding to if a invalid
pointer was provided, causing the dereference to go awry.
If a valid non-current task was provided, the locking should be ok as we
disable irqs while the write_seqlock is held in set_task_comm().
The only places this could cause a problem was if you tried to printk
with a %ptc while holding the task->comm_lock. However, the lock is only
shortly held in task_comm_string, and get_task_comm and set_task_comm.
So it is fairly easy to audit for correctness.
If there is some other situation you had in mind, please let me know.
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