linux-ext4 - Re: [PATCH 4/4] ext4: Wait for proper transaction commit on fsync

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]

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