From: Mark Syms <Mark.Syms@citrix.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] kernel BUG at fs/gfs2/inode.h:64
Date: Wed, 9 Jan 2019 13:43:50 +0000 [thread overview]
Message-ID: <ece7069401bd4646878e830285e5b9c5@AMSPEX02CL02.citrite.net> (raw)
In-Reply-To: <CAHc6FU78YCBXDAfxk78QVMWVqLu392X5cvJjHoU-B8H1AjHVmw@mail.gmail.com>
We don't yet know how the assert got triggered as we've only seen it once and in the original form it looks like it would be very hard to trigger in any normal case (given that in default usage i_blocks should be at least 8 times what any putative value for change could be). So, for the assert to have triggered we've been asked to remove at least 8 times the number of blocks currently allocated to the inode. Possible causes could be a double release or some other higher level bug that will require further investigation to uncover.
Mark.
-----Original Message-----
From: Andreas Gruenbacher <agruenba@redhat.com>
Sent: 09 January 2019 13:31
To: Tim Smith <tim.smith@citrix.com>
Cc: cluster-devel <cluster-devel@redhat.com>; Igor Druzhinin <igor.druzhinin@citrix.com>; Mark Syms <Mark.Syms@citrix.com>
Subject: Re: [Cluster-devel] kernel BUG at fs/gfs2/inode.h:64
Mark and Tim,
On Wed, 9 Jan 2019 at 13:05, Tim Smith <tim.smith@citrix.com> wrote:
> On Tuesday, 8 January 2019 13:32:20 GMT Mark Syms wrote:
> > Hi,
> >
> > We've seen this in testing with 4.19.
> >
> > Full trace is at the bottom.
> >
> > Looking at the code though it looks like it will assert if the value
> > of change is equal to the number of blocks currently allocated to the inode.
> > Is this expected or should the assert be using >= instead of > ?
>
> It's weirder. Looking at
>
> static inline void gfs2_add_inode_blocks(struct inode *inode, s64
> change) {
> gfs2_assert(GFS2_SB(inode), (change >= 0 || inode->i_blocks > -change));
> change *= (GFS2_SB(inode)->sd_sb.sb_bsize/GFS2_BASIC_BLOCK);
> inode->i_blocks += change;
> }
>
> where the BUG is happening, "inode->i_blocks" is counting of 512b
> blocks and "change" is in units of whatever-the-superblock-said which
> will probably be counting 4096b blocks, so the comparison makes no sense.
indeed. I wonder why this hasn't been discovered long ago.
> It should probably read
>
> static inline void gfs2_add_inode_blocks(struct inode *inode, s64
> change) {
> change *= (GFS2_SB(inode)->sd_sb.sb_bsize/GFS2_BASIC_BLOCK);
> gfs2_assert(GFS2_SB(inode), (change >= 0 || inode->i_blocks >= -change));
> inode->i_blocks += change;
> }
>
> so I'll make a patch for that unless someone wants to correct me.
You can just shift by (inode->i_blkbits - 9).
Can you still trigger the assert with this fix?
Thanks,
Andreas
next prev parent reply other threads:[~2019-01-09 13:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-08 13:32 [Cluster-devel] kernel BUG at fs/gfs2/inode.h:64 Mark Syms
2019-01-09 12:05 ` Tim Smith
2019-01-09 13:31 ` Andreas Gruenbacher
2019-01-09 13:43 ` Mark Syms [this message]
2019-01-09 15:35 ` Andreas Gruenbacher
2019-01-09 17:14 ` Tim Smith
2019-01-09 17:18 ` Steven Whitehouse
2019-01-09 17:24 ` Andreas Gruenbacher
2019-01-09 18:43 ` Mark Syms
2019-01-09 20:00 ` Andreas Gruenbacher
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=ece7069401bd4646878e830285e5b9c5@AMSPEX02CL02.citrite.net \
--to=mark.syms@citrix.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 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).