From: Eric Sandeen <sandeen@redhat.com>
To: Gordan Bobic <gordan@bobich.net>
Cc: linux-ext4@vger.kernel.org
Subject: Re: e2fsprogs alignment issues
Date: Wed, 11 Jul 2012 10:04:51 -0500 [thread overview]
Message-ID: <4FFD9613.3050305@redhat.com> (raw)
In-Reply-To: <4FFD7D9B.2080503@bobich.net>
On 7/11/12 8:20 AM, Gordan Bobic wrote:
> I would like to bring the following bug report to people's
> attention:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=680090
>
> The issue is that the code used in e2fsprogs WRT allocating unaligned
> buffers and then casting them into structs is non-portable and
> dangerous - eyewateringly dangerous in something like e2fsprogs where
> it can lead to thorough trashing of the file system.
>
> Can something be done to improve the portability of the userspace
> code?
>
> The issue has been discussed on the Fedora-ARM mailing list:
> http://lists.fedoraproject.org/pipermail/arm/2012-July/003637.html
> but the argument there was that the issue needs to be fixed upstream,
> hence why I am posting it here.
>
> This is an issue on all ARMs up to ARMv5, possibly ARMv6, and likely
> other CPU architectures that don't have transparent alignment fixup
> in hardware (Itanium, SPARC, probably others).
>
> Apart from being dangerous, using unaligned arrays also affects
> performance because it leads to data needlessly straddling cache
> lines in the CPU. But that doesn't really matter in this case.
For what it's worth, I've never seen reports from anywhere that indicate
that it didn't get fixed up. But I agree that if we can eliminate the need
for the fixups it'd be best.
Many of these are the result of things like:
char buf[4096] = "";
struct fiemap *fiemap = (struct fiemap *)buf;
Ted, is this construct just an attempt to avoid malloc/free for
simplicity of the code? 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.
Gordan, until I get handy access to a real arm box, if you could do a
"make check" in the e2fsprogs tree, it might flush out a few more
of these alignment warnings, and adding them all to the bug for tracking
purposes might be helpful.
(IIRC "make gcc-wall" will also emit warnings for casts which change
natural alignment, among other things)
Thanks,
-Eric
> Many thanks.
next prev parent reply other threads:[~2012-07-11 15:05 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 [this message]
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
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=4FFD9613.3050305@redhat.com \
--to=sandeen@redhat.com \
--cc=gordan@bobich.net \
--cc=linux-ext4@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).