LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* On spreading atomic_t initialization
@ 2008-10-28 15:29 Alexey Dobriyan
  2008-10-28 15:54 ` Matthew Wilcox
  2008-10-28 16:16 ` Linus Torvalds
  0 siblings, 2 replies; 3+ messages in thread
From: Alexey Dobriyan @ 2008-10-28 15:29 UTC (permalink / raw)
  To: torvalds, akpm; +Cc: linux-kernel, linux-arch

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()?

Given the following patch, there is none almost certainly.

--- a/kernel/user.c
+++ b/kernel/user.c
@@ -405,6 +405,9 @@ struct user_struct *alloc_uid(struct user_namespace *ns, uid_t uid)
 
 		new->uid = uid;
 		atomic_set(&new->__count, 1);
+		atomic_set(&new->processes, 0);
+		atomic_set(&new->files, 0);
+		atomic_set(&new->sigpending, 0);
 
 		if (sched_create_user(new) < 0)
 			goto out_free_user;


Such checker will still be useful to catch genuine uninitialized usages,
but the amount of stuff to shut up before it can realistically be put in -mm
is amazing.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: On spreading atomic_t initialization
  2008-10-28 15:29 On spreading atomic_t initialization Alexey Dobriyan
@ 2008-10-28 15:54 ` Matthew Wilcox
  2008-10-28 16:16 ` Linus Torvalds
  1 sibling, 0 replies; 3+ messages in thread
From: Matthew Wilcox @ 2008-10-28 15:54 UTC (permalink / raw)
  To: Alexey Dobriyan; +Cc: torvalds, akpm, linux-kernel, linux-arch

On Tue, Oct 28, 2008 at 06:29:43PM +0300, 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()?

No.  atomic_t is 32-bit, and requires all 32 bits to be usable by the
callers.  It's kind of like NULL might not theoretically be represented
by a bit-pattern of all zeroes.  In practise, it always is.  I don't
see the value in your checker, sorry.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: On spreading atomic_t initialization
  2008-10-28 15:29 On spreading atomic_t initialization Alexey Dobriyan
  2008-10-28 15:54 ` Matthew Wilcox
@ 2008-10-28 16:16 ` Linus Torvalds
  1 sibling, 0 replies; 3+ messages in thread
From: Linus Torvalds @ 2008-10-28 16:16 UTC (permalink / raw)
  To: Alexey Dobriyan; +Cc: akpm, linux-kernel, linux-arch



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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-10-28 16:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-28 15:29 On spreading atomic_t initialization Alexey Dobriyan
2008-10-28 15:54 ` Matthew Wilcox
2008-10-28 16:16 ` Linus Torvalds

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).