Date: Tue, 28 Oct 2008 09:16:40 -0700 (PDT)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alexey Dobriyan <adobriyan@gmail.com>
cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
       linux-arch@vger.kernel.org
Subject: Re: On spreading atomic_t initialization
In-Reply-To: <20081028152943.GA20989@x200.localdomain>
Message-ID: <alpine.LFD.2.00.0810280905350.3386@nehalem.linux-foundation.org>
References: <20081028152943.GA20989@x200.localdomain>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1613
Lines: 37


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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/