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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20091209143219.GF27692@thunk.org>
Date:	Wed, 9 Dec 2009 09:32:19 -0500
From:	tytso@....edu
To:	Jan Kara <jack@...e.cz>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 4/4] ext4: Wait for proper transaction commit on fsync

On Wed, Dec 09, 2009 at 12:29:40PM +0100, Jan Kara wrote:
> On Tue 08-12-09 23:54:24, tytso@....edu wrote:
> > Here's a revised version of your patch that I've included in the ext4
> > patch queue.  I've removed the use of the atomic_t data type.  I've
>   OK, I'm just unsure: Isn't even 32-bit read non-atomic if it is not
> properly aligned e.g. on powerPC? So shouldn't we make sure those inode
> fields are aligned to 32-bit boundary (or at least add a comment about
> that)?

But gcc guarantees such alignments, unless you do something horrible
from a performance point of view, such as using
__attribute__((packed)).  And in fact, if things are not aligned, on
some platforms unaligned access will trigger a software trap, and the
kernel trap handler has to fix up the unaligned access.  (I believe
Power is one of these platforms if memory serves correctly.)  Even on
platforms that don't, the performance hit where the hardware has to do
the unaligned access so horrible that gcc avoids the misalignment
automatically.

That's why sometimes I'll go around and try to adjust structure member
orders, since something like this:

struct foo {
       short int a;
       int   b;
       short int c;
} foo_array[2];

Will consume 24 bytes.... while this:

struct foo {
       short int a;
       short int c;
       int   b;
} foo_array[2];

... will consume 16 bytes.  For structures that are used in huge
amounts (like inode slab caches), it can mean a measurable memory
savings.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ