| 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: Wed, 4 Apr 2007 12:01:48 +0200 From: Ingo Molnar <mingo@...e.hu> To: Oleg Nesterov <oleg@...sign.ru> Cc: Andrew Morton <akpm@...ux-foundation.org>, Ulrich Drepper <drepper@...hat.com>, Linux Kernel <linux-kernel@...r.kernel.org>, Gautham R Shenoy <ego@...ibm.com>, Dipankar Sarma <dipankar@...ibm.com>, Paul Jackson <pj@....com> Subject: Re: getting processor numbers * Oleg Nesterov <oleg@...sign.ru> wrote: > On 04/04, Ingo Molnar wrote: > > > > * Oleg Nesterov <oleg@...sign.ru> wrote: > > > > > But we don't need tasklist_lock at all, we can use > > > rcu_read_lock/unlock. Q: don't we need task_rq_lock() to read > > > ->cpus_allowed "atomically" ? > > > > right now ->cpus_allowed is protected by tasklist_lock. We cannot do > > RCU here because ->cpus_allowed modifications are not RCUified. > > Is it so? that was my question. Afaics, set_cpus_allowed() does > p->cpus_allowed = new_mask under rq->lock, so I don't understand how > tasklist_lock can help. you are right, we could (and should) make this depend on rq_lock only - i.e. just take away the tasklist_lock like your patch does. It's not like the user could expect to observe any ordering between PID lookup and affinity-mask changes. And my RCU comment is bogus: it's not like we allocate ->cpus_allowed :-/ Ingo - 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