| 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: Mon, 28 Mar 2011 08:56:54 +0100 From: Matt Fleming <matt@...sole-pimps.org> To: Oleg Nesterov <oleg@...hat.com> Cc: linux-kernel@...r.kernel.org Subject: __lock_task_sighand() and RCU Hi Oleg, I've been reading __lock_task_sighand() and I can't quite wrap my head around what the rcu_read_lock()/rcu_read_unlock() is protecting in there. Initially I assumed that it was protecting the 'tsk' argument, but realised that can't be right because all rcu_read_lock() guarantees is that if tsk is valid when we enter the read section, it will remain valid throughout the rcu read side section. It doesn't guarantee that when we enter the read side section 'tsk' _will_ be valid; the callers are required to lookup and verify the value of 'tsk' before they call __lock_task_sighand() (possibly by calling __lock_task_sighand() from within an rcu_read_lock() section). Then I wondered if it was protecting the sighand from being freed from under us while we're trying to lock it. But sighands aren't freed via rcu, it's just a simple refcnt and kmem_cache_free() deal in __cleanup_sighand() with all synchronization done via the siglock. So what does that rcu_read_lock() protect? I'm most likely missing some obvious detail but if you could help me out I'd appreciate it! -- Matt Fleming, Intel Open Source Technology Center -- 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