On Tue, 28 Oct 2008, Alexey Dobriyan wrote: > > I wrote stupid runtime checker to look for atomic_t uninitialized usage > and the amount of screaming in logs is surprisingly very big. > > So the question: is there really really an arch for which setting atomic_t > by hand (kzalloc) is not equivalent to atomic_set()? For _initializers_? Not any more. And never for zero values. We used to have very strict rules because 32-bit sparc historically used to use the low byte as a lock byte, but even back then it was ok to initialize the values with zero, and you had to use atomic_set() only if you set it to some other value (because the thing needed to be shifted up by eight bits in order to avoid the lock byte). But zero has always been safe, and in fact since then we've also simply required that "atomic_t" always has at least 32 bits of data, and sparc fixed its implementation to have the lock separately for the broken old sparc32 architectures that don't have good atomic handling. So it might possibly still be valid to check that an atomic_t is initialized properly, but setting it to zero is a special case, and so it's ok to initialize it with a zeroing allocation (kzalloc()) or simply with a 'memset(ptr, 0, size)'. I bet that if you change your checker to accept zero initializations, you won't find any issues any more. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
