* 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 read-only IMAP folder(s) and NNTP newsgroup(s).