From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Mon, 6 Mar 2017 15:15:44 +0000 Subject: [Cluster-devel] [PATCH] gfs2: Avoid alignment hole in struct lm_lockname In-Reply-To: <1488810836-11427-1-git-send-email-agruenba@redhat.com> References: <1488810836-11427-1-git-send-email-agruenba@redhat.com> Message-ID: <3685ca8e-184b-dee6-82d0-3fe6ebd5ddd7@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, On 06/03/17 14:33, Andreas Gruenbacher wrote: > Commit 88ffbf3e03 switches to using rhashtables for glocks, hashing over > the entire struct lm_lockname instead of its individual fields. On some > architectures, struct lm_lockname contains a hole of uninitialized > memory due to alignment rules, which now leads to incorrect hash values. > Get rid of that hole. > > Signed-off-by: Andreas Gruenbacher > CC: #v4.3+ > --- > fs/gfs2/incore.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/gfs2/incore.h b/fs/gfs2/incore.h > index c45084a..511e1ed 100644 > --- a/fs/gfs2/incore.h > +++ b/fs/gfs2/incore.h > @@ -207,7 +207,7 @@ struct lm_lockname { > struct gfs2_sbd *ln_sbd; > u64 ln_number; > unsigned int ln_type; > -}; > +} __packed __aligned(sizeof(int)); > > #define lm_name_equal(name1, name2) \ > (((name1)->ln_number == (name2)->ln_number) && \ I'm still not sure that this is the best solution. Also, either it should be packed or aligned to a certain size, I'm not sure how it can be both? Changing the alignment may cause access issues on some arches. I think it would be better just to initialize the structure to zero when we allocate a new glock, that will ensure that the padding is always zeroed, without changing the alignment, Steve.