LKML Archive on
help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Alexey Dobriyan <>
Subject: Re: On spreading atomic_t initialization
Date: Tue, 28 Oct 2008 09:16:40 -0700 (PDT)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20081028152943.GA20989@x200.localdomain>

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. 


      parent reply	other threads:[~2008-10-28 16:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28 15:29 Alexey Dobriyan
2008-10-28 15:54 ` Matthew Wilcox
2008-10-28 16:16 ` Linus Torvalds [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: On spreading atomic_t initialization' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).