From: Andrew Price <anprice@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Review of gfs2-utils test failure and gfs2_dirent changes
Date: Tue, 16 Feb 2016 13:20:14 +0000 [thread overview]
Message-ID: <56C3220E.2020807@redhat.com> (raw)
Hi,
As a recent build failure[0] happened due to changes in the layout of
struct gfs2_dirent causing a (broken) test to fail, I felt it would be a
good idea to step through it carefully to make sure the struct changes
haven't introduced a subtle bug.
The package build failure was caused by the libgfs2/meta.c unit test
failing with this error message:
gfs2_dirent: __pad: offset is 28, expected 26
gfs2_dirent: size mismatch between struct 40 and fields 38
The fact that it was even looking at the __pad field was curious as the
code generating the values was
#ifdef GFS2_HAS_DE_RAHEAD
F(de_rahead)
RF(__pad2)
#else
RF(__pad)
#endif
and GFS2_HAS_DE_RAHEAD should have been defined at that point. It turned
out that this was due to meta.c not #including clusterautoconfig.h which
contains the GFS2_HAS_* defines set by autoconf.
So why did the offset of __pad change, and the struct size (appear to)
change? Originally the __pad field occupied the last 14 bytes of the struct:
struct gfs2_dirent {
...
// Offset 26:
__u8 __pad[14];
};
And then the de_rahead field was added, leaving the __pad field
unchanged and unioned with the new field and padding:
struct gfs2_dirent {
...
// Offset 26:
union {
__u8 __pad[14];
struct {
__be16 de_rahead;
__u8 pad2[12];
};
};
};
This didn't cause a test failure because __pad was still 14 bytes and
where it was expected to be, but then the de_cookie change[1] moved
things around slightly:
struct gfs2_dirent {
...
// Offset 26:
__be16 de_rahead;
union {
__u8 __pad[12];
struct {
__u32 de_cookie; /* ondisk value not used */
__u8 pad3[8];
};
};
};
So de_rahead is still at offset 26, no longer unioned with __pad but
still occupying the first 2 bytes of the 14, and __pad has become 2
bytes smaller to reflect that. This caused the test to fail because it
knew nothing about de_rahead now lying outside of the union and so still
expected __pad to be at offset 26 (calculated additively).
In conclusion, it doesn't look like there's a bug in gfs2 here as the
offsets and sizes of the used fields haven't changed, and the test
failure was entirely due to the buggy test.
Andy
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1307532
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=471f3db
reply other threads:[~2016-02-16 13:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=56C3220E.2020807@redhat.com \
--to=anprice@redhat.com \
/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.