* [Cluster-devel] GFS2: pull request for high-priority bug [not found] <186538212.2600624.1489588290616.JavaMail.zimbra@redhat.com> @ 2017-03-15 14:32 ` Bob Peterson 0 siblings, 0 replies; 6+ messages in thread From: Bob Peterson @ 2017-03-15 14:32 UTC (permalink / raw) To: cluster-devel.redhat.com Hi Linus, Please consider pulling the following additional patch for the GFS2 file system. Regards, Bob Peterson ---------------------------------------------------------------- The following changes since commit ae50dfd61665086e617cc9e554a1285d52765670: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-03-14 21:31:23 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git tags/gfs2-4.11-rc3.fixes for you to fetch changes up to 28ea06c46fbcab63fd9a55531387b7928a18a590: gfs2: Avoid alignment hole in struct lm_lockname (2017-03-15 10:06:07 -0400) ---------------------------------------------------------------- This is an emergency patch for 4.11-rc3 The GFS2 developers uncovered a really nasty problem that can lead to random corruption and kernel panic, much like the last one. Andreas Gruenbacher wrote this simple one-line patch to fix the problem: 28ea06c gfs2: Avoid alignment hole in struct lm_lockname ---------------------------------------------------------------- Andreas Gruenbacher (1): gfs2: Avoid alignment hole in struct lm_lockname fs/gfs2/incore.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [flat|nested] 6+ messages in thread
* GFS2: pull request for high-priority bug @ 2017-03-15 14:32 ` Bob Peterson 0 siblings, 0 replies; 6+ messages in thread From: Bob Peterson @ 2017-03-15 14:32 UTC (permalink / raw) To: torvalds; +Cc: cluster-devel, linux-kernel Hi Linus, Please consider pulling the following additional patch for the GFS2 file system. Regards, Bob Peterson ---------------------------------------------------------------- The following changes since commit ae50dfd61665086e617cc9e554a1285d52765670: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-03-14 21:31:23 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git tags/gfs2-4.11-rc3.fixes for you to fetch changes up to 28ea06c46fbcab63fd9a55531387b7928a18a590: gfs2: Avoid alignment hole in struct lm_lockname (2017-03-15 10:06:07 -0400) ---------------------------------------------------------------- This is an emergency patch for 4.11-rc3 The GFS2 developers uncovered a really nasty problem that can lead to random corruption and kernel panic, much like the last one. Andreas Gruenbacher wrote this simple one-line patch to fix the problem: 28ea06c gfs2: Avoid alignment hole in struct lm_lockname ---------------------------------------------------------------- Andreas Gruenbacher (1): gfs2: Avoid alignment hole in struct lm_lockname fs/gfs2/incore.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Cluster-devel] GFS2: pull request for high-priority bug 2017-03-15 14:32 ` Bob Peterson @ 2017-03-15 17:21 ` Linus Torvalds -1 siblings, 0 replies; 6+ messages in thread From: Linus Torvalds @ 2017-03-15 17:21 UTC (permalink / raw) To: cluster-devel.redhat.com On Wed, Mar 15, 2017 at 7:32 AM, Bob Peterson <rpeterso@redhat.com> wrote: > > Andreas Gruenbacher (1): > gfs2: Avoid alignment hole in struct lm_lockname So I've pulled this because I think it fixes a real bug, but honestly I think it's the wrong fix. Marking that lm_lockname structure "packed, aligned(4)" means that the compiler will now think that the 64-bit fields in it may be unaligned - including on architectures where that can be very expensive and the compiler now might generate stupid unaligned instruction sequences to load those values. So the *correct* fix, I think, would have been: - add a comment about not having holes in the struct due to the hashing - sort the fields by size (so "ln_number" first, then "ln_sbd", then "ln_type") - use offsetofend(struct lm_lockname, ln_type) instead of sizeof() when hashing which avoids the "possibly generate garbage code" issue due to the quick-and-dirty one-liner approach. Hmm? Linus ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GFS2: pull request for high-priority bug @ 2017-03-15 17:21 ` Linus Torvalds 0 siblings, 0 replies; 6+ messages in thread From: Linus Torvalds @ 2017-03-15 17:21 UTC (permalink / raw) To: Bob Peterson, Andreas Gruenbacher Cc: cluster-devel, Linux Kernel Mailing List On Wed, Mar 15, 2017 at 7:32 AM, Bob Peterson <rpeterso@redhat.com> wrote: > > Andreas Gruenbacher (1): > gfs2: Avoid alignment hole in struct lm_lockname So I've pulled this because I think it fixes a real bug, but honestly I think it's the wrong fix. Marking that lm_lockname structure "packed, aligned(4)" means that the compiler will now think that the 64-bit fields in it may be unaligned - including on architectures where that can be very expensive and the compiler now might generate stupid unaligned instruction sequences to load those values. So the *correct* fix, I think, would have been: - add a comment about not having holes in the struct due to the hashing - sort the fields by size (so "ln_number" first, then "ln_sbd", then "ln_type") - use offsetofend(struct lm_lockname, ln_type) instead of sizeof() when hashing which avoids the "possibly generate garbage code" issue due to the quick-and-dirty one-liner approach. Hmm? Linus ^ permalink raw reply [flat|nested] 6+ messages in thread
* [Cluster-devel] GFS2: pull request for high-priority bug 2017-03-15 17:21 ` Linus Torvalds @ 2017-03-15 17:40 ` Bob Peterson -1 siblings, 0 replies; 6+ messages in thread From: Bob Peterson @ 2017-03-15 17:40 UTC (permalink / raw) To: cluster-devel.redhat.com ----- Original Message ----- | On Wed, Mar 15, 2017 at 7:32 AM, Bob Peterson <rpeterso@redhat.com> wrote: | > | > Andreas Gruenbacher (1): | > gfs2: Avoid alignment hole in struct lm_lockname | | So I've pulled this because I think it fixes a real bug, but honestly | I think it's the wrong fix. | | Marking that lm_lockname structure "packed, aligned(4)" means that the | compiler will now think that the 64-bit fields in it may be unaligned | - including on architectures where that can be very expensive and the | compiler now might generate stupid unaligned instruction sequences to | load those values. | | So the *correct* fix, I think, would have been: | | - add a comment about not having holes in the struct due to the hashing | | - sort the fields by size (so "ln_number" first, then "ln_sbd", then | "ln_type") | | - use offsetofend(struct lm_lockname, ln_type) instead of sizeof() when | hashing | | which avoids the "possibly generate garbage code" issue due to the | quick-and-dirty one-liner approach. | | Hmm? | | Linus Hi Linus, Thanks. Yes, good ideas. I see your point and I'll see if we can get that fixed up for the next merge window. Bob Peterson ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GFS2: pull request for high-priority bug @ 2017-03-15 17:40 ` Bob Peterson 0 siblings, 0 replies; 6+ messages in thread From: Bob Peterson @ 2017-03-15 17:40 UTC (permalink / raw) To: Linus Torvalds Cc: Andreas Gruenbacher, cluster-devel, Linux Kernel Mailing List ----- Original Message ----- | On Wed, Mar 15, 2017 at 7:32 AM, Bob Peterson <rpeterso@redhat.com> wrote: | > | > Andreas Gruenbacher (1): | > gfs2: Avoid alignment hole in struct lm_lockname | | So I've pulled this because I think it fixes a real bug, but honestly | I think it's the wrong fix. | | Marking that lm_lockname structure "packed, aligned(4)" means that the | compiler will now think that the 64-bit fields in it may be unaligned | - including on architectures where that can be very expensive and the | compiler now might generate stupid unaligned instruction sequences to | load those values. | | So the *correct* fix, I think, would have been: | | - add a comment about not having holes in the struct due to the hashing | | - sort the fields by size (so "ln_number" first, then "ln_sbd", then | "ln_type") | | - use offsetofend(struct lm_lockname, ln_type) instead of sizeof() when | hashing | | which avoids the "possibly generate garbage code" issue due to the | quick-and-dirty one-liner approach. | | Hmm? | | Linus Hi Linus, Thanks. Yes, good ideas. I see your point and I'll see if we can get that fixed up for the next merge window. Bob Peterson ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-03-15 17:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <186538212.2600624.1489588290616.JavaMail.zimbra@redhat.com>
2017-03-15 14:32 ` [Cluster-devel] GFS2: pull request for high-priority bug Bob Peterson
2017-03-15 14:32 ` Bob Peterson
2017-03-15 17:21 ` [Cluster-devel] " Linus Torvalds
2017-03-15 17:21 ` Linus Torvalds
2017-03-15 17:40 ` [Cluster-devel] " Bob Peterson
2017-03-15 17:40 ` Bob Peterson
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.