From: Eric Sandeen <sandeen@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Gordan Bobic <gordan@bobich.net>, linux-ext4@vger.kernel.org
Subject: Re: e2fsprogs alignment issues
Date: Wed, 11 Jul 2012 16:26:08 -0500 [thread overview]
Message-ID: <4FFDEF70.3090202@redhat.com> (raw)
In-Reply-To: <20120711200557.GB5838@thunk.org>
On 7/11/12 3:05 PM, Theodore Ts'o wrote:
> On Wed, Jul 11, 2012 at 10:04:51AM -0500, Eric Sandeen wrote:
...
>> I think Gordan suggested (if I understand it
>> right) that doing an array of ints might also solve the problem, since
>> ints should be on natural alignment. Or maybe in some cases malloc/free
>> would be more obvious, if handling errors isn't too tricky.
>
> In the specific case which Gordon has pointed out, the obvious thing
> to do is to just to set errno to ENOMEM, and return -1. since we
> already reflect an error code up to the caller if the FIEMAP ioctl()
> fails.
>
> If someone sends me the patch, I will happily apply it.
Sure, I was planning on it :)
>> (IIRC "make gcc-wall" will also emit warnings for casts which change
>> natural alignment, among other things)
>
> I'd have to check to be sure, but I don't think so, since it would
> have way too many false positives. We *do* have code where we take
> char *'s and and then cast them to some other pointer type, and then
> dereference them. And we do currently assume that it is safe to do
> this for on-disk data structures which are 4 byte aligned, in the
> directory entry code, for example.
>
> I will *not* accept a patch which uses memcpy to copy each field in
> the on-disk superblock, or directory entry, into an int, just in case
> there is some insane architecture which requires that 4 byte integers
> be 32-byte aligned, or something else insane like that.
Well, let's just see where we're at, first, and see what it'll take,
case by case.
-Eric
next prev parent reply other threads:[~2012-07-11 21:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-11 13:20 e2fsprogs alignment issues Gordan Bobic
2012-07-11 15:04 ` Eric Sandeen
2012-07-11 20:05 ` Theodore Ts'o
2012-07-11 21:22 ` Gordan Bobic
2012-07-12 0:05 ` Theodore Ts'o
2012-07-11 21:26 ` Eric Sandeen [this message]
2012-07-13 22:25 ` Dave Chinner
2012-07-11 21:24 ` Gordan Bobic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FFDEF70.3090202@redhat.com \
--to=sandeen@redhat.com \
--cc=gordan@bobich.net \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.