KEYS: Use RCU dereference wrappers in keyring key type code
in [Kernel]
|
Prev: [RFC][PATCH 1/12 applied today] KVM: x86: avoid unnecessary bitmap allocation when memslot is clean
Next: [RFC][PATCH 7/12 not tested yet] PPC: introduce __set_bit() like function for bitmaps in user space
From: David Howells on 4 May 2010 09:10 Serge E. Hallyn <serue(a)us.ibm.com> wrote: > <shrug> does this mean that the > klist = rcu_dereference_check(keyring->payload.subscriptions, > lockdep_is_held(&key_serial_lock)); > in security/keys/gc.c:key_gc_keyring() should become a > rcu_dereference_protected() to avoid the rcu_dereference_raw() and for > consistency? Well spotted. That's incorrect modification by commit e7b0a61b7929632d36cf052d9e2820ef0a9c1bfe. key_serial_lock is not a guarantor of the current keyring subscriptions not changing as we read it. We need to hold either the RCU read lock (so that the what the pointer currently points to isn't trashed) or the keyring semaphore (so that the keyring isn't changed under us). The real error is not holding the RCU read lock (I'd assumed that the fact it was holding a spinlock implied this - which I now know to be wrong). David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |