linux-kernel - Re: [PATCH] fs: fix lock initialization

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Jul 2011 10:40:44 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	akpm@...ux-foundation.org, stable@...nel.org
Subject: Re: [PATCH] fs: fix lock initialization

On Wed, Jul 6, 2011 at 3:33 AM, Miklos Szeredi <miklos@...redi.hu> wrote:
>
> locks_alloc_lock() assumed that the allocated struct file_lock is
> already initialized to zero members.  This is only true for the first
> allocation of the structure, after reuse some of the members will have
> random values.

Ugh. Code that depends on SLAB initializers is broken.

The reason for those initializers are traditionally "better cache
behavior" where you don't need to initialize everything at allocation
time, but the whole concept is almost invariably a disaster. This is a
prime example of it.

I also doubt the cache value - what happens is that you tend to touch
_part_ of the cachelines instead of just clearing the whole thing,
which is quite often not at all more efficient. And even when you are
able to avoid touching a cacheline entirely, most of the time it just
moves the cache miss cost elsewhere to the user.

There are some valid uses of initializers (eg code that depends on RCU
freeing and very much is about not re-initializing a lock), but they
really are about those kinds special cases. We should try to encourage
people to limit initializers to *only* those kinds of things.

Thanks for noticing,

               Linus
--
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/