Re: [PATCH] fs: fix lock initialization

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, Jul 6, 2011 at 3:33 AM, Miklos Szeredi <miklos@szeredi.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