linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruenba@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "K.V, Aneesh" <aneesh.kumar@linux.vnet.ibm.com>,
	cluster-devel <cluster-devel@redhat.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: gfs2 iomap: BUG_ON(buffer_unmapped) in submit_bh_wbc
Date: Thu, 24 May 2018 20:05:03 +0200	[thread overview]
Message-ID: <CAHc6FU5a5E9K_AizwWkoPjb4cCWzqKspjc9YDVOzpCxcsDnKeA@mail.gmail.com> (raw)

Hi Christoph,

I'm running into the following problem with the GFS2 iomap patches:

In order to get iomap_to_bh to set the New flag of bhs for newly
allocated blocks in __block_write_begin_int, I set iomap->type to
IOMAP_UNWRITTEN when allocating blocks. This has the side effect of
setting the Unwritten bh flag as well. GFS2 doesn't have the concept
of unwritten extents, so it doesn't use the Unwritten flag itself.
There's also nothing in gfs2 that would clear that flag.

When I write to a file on that filesystem with something like:

  xfs_io -t -f -c "pwrite -S 0x5a 2048 2048" -c "fsync" /mnt/scratch/foo

I run into a BUG_ON(buffer_unwritten(bh)) in __mpage_writepage ->
__block_write_full_page -> submit_bh_wbc. That BUG_ON was added in
commit 8fb0e34248 by Aneesh. So clearly the VFS expects the unwritten
flags to be cleared by the filesystem somewhere.

I can think of two ways to fix this:

(1) make iomap_to_bh set the buffer_new flag for IOMAP_MAPPED mappings
with the IOMAP_F_NEW flag set as well and stop abusing the Unwritten
bh flag,

(2) clear the Unwritten flags in the filesystem.


Approach (1) is quite trivial:

--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1908,7 +1908,7 @@ iomap_to_bh(struct inode *inode, sector_t,
struct buffer_head *bh,
                set_buffer_unwritten(bh);
                /* FALLTHRU */
        case IOMAP_MAPPED:
-               if (offset >= i_size_read(inode))
+               if ((iomap->flags & IOMAP_F_NEW) || offset >=
i_size_read(inode))
                        set_buffer_new(bh);
                bh->b_blocknr = (iomap->addr + offset - iomap->offset) >>
                                inode->i_blkbits;


If you think (2) is preferable, then where and when should the
filesystem clear the Unwritten bh flags?


Thanks,
Andreas

             reply	other threads:[~2018-05-24 18:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-24 18:05 Andreas Gruenbacher [this message]
2018-05-24 18:13 ` gfs2 iomap: BUG_ON(buffer_unmapped) in submit_bh_wbc Christoph Hellwig
2018-05-24 18:25   ` Andreas Gruenbacher
2018-05-25 12:24     ` Christoph Hellwig

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=CAHc6FU5a5E9K_AizwWkoPjb4cCWzqKspjc9YDVOzpCxcsDnKeA@mail.gmail.com \
    --to=agruenba@redhat.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=cluster-devel@redhat.com \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@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).