From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by kanga.kvack.org (Postfix) with ESMTP id 4393D900001 for ; Thu, 28 Apr 2011 20:05:02 -0400 (EDT) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3SNca99006814 for ; Thu, 28 Apr 2011 19:38:36 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3T04xUn1192102 for ; Thu, 28 Apr 2011 20:04:59 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3SK4l01022298 for ; Thu, 28 Apr 2011 17:04:48 -0300 Subject: Re: [PATCH 1/2] break out page allocation warning code From: john stultz In-Reply-To: <1304034500.2971.160.camel@work-vm> References: <1303331695.2796.159.camel@work-vm> <20110421103009.731B.A69D9226@jp.fujitsu.com> <1303846026.2816.117.camel@work-vm> <1303950728.2971.35.camel@work-vm> <1303954193.2971.43.camel@work-vm> <1304034500.2971.160.camel@work-vm> Content-Type: text/plain; charset="UTF-8" Date: Thu, 28 Apr 2011 17:04:55 -0700 Message-ID: <1304035495.2971.169.camel@work-vm> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: KOSAKI Motohiro , Dave Hansen , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Johannes Weiner , Michal Nazarewicz , Andrew Morton On Thu, 2011-04-28 at 16:48 -0700, john stultz wrote: > On Thu, 2011-04-28 at 15:48 -0700, David Rientjes wrote: > > On Wed, 27 Apr 2011, john stultz wrote: > > > > > So thinking further, this can be simplified by adding the seqlock first, > > > and then retaining the task_locking only in the set_task_comm path until > > > all comm accessors are converted to using get_task_comm. > > > > > > > On second thought, I think it would be better to just retain using a > > spinlock but instead of using alloc_lock, introduce a new spinlock to > > task_struct for the sole purpose of protecting comm. > > > > And, instead, of using get_task_comm() to write into a preallocated > > buffer, I think it would be easier in the vast majority of cases that > > you'll need to convert to just provide task_comm_lock(p) and > > task_comm_unlock(p) so that p->comm can be dereferenced safely. Ok.. trying to find a middle ground here by replying to my own concerns. :) > So my concern with this is that it means one more lock that could be > mis-nested. By keeping the locking isolated to the get/set_task_comm, we > can be sure that won't happen. > > Also tracking new current->comm references will be easier if we just > don't allow new ones. Validating that all the comm references are > correctly locked becomes more difficult if we need locking at each use > site. So maybe we still ban current->comm access and instead have a lightweight get_comm_locked() accessor or something that. Then we can add debugging options to validate that the lock is properly held internally. > Further, since I'm not convinced that we never reference current->comm > from irq context, if we go with spinlocks, we're going to have to > disable irqs in the read path as well. seqlocks were nice for that > aspect. rwlocks can resolve this concern. Any other thoughts? -john -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org