lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081028152943.GA20989@x200.localdomain>
Date:	Tue, 28 Oct 2008 18:29:43 +0300
From:	Alexey Dobriyan <adobriyan@...il.com>
To:	torvalds@...l.org, akpm@...l.org
Cc:	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: On spreading atomic_t initialization

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ