lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 28 Apr 2011 17:04:55 -0700 From: john stultz <johnstul@...ibm.com> To: David Rientjes <rientjes@...gle.com> Cc: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, Dave Hansen <dave@...ux.vnet.ibm.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, Johannes Weiner <hannes@...xchg.org>, Michal Nazarewicz <mina86@...a86.com>, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: [PATCH 1/2] break out page allocation warning code 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 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