Re: xfs_vm_releasepage() causing BUG at free_buffer_head()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Holger,

Thank you for your response. I see that xfs_finish_page_writeback() has been added very recently and is called from xfs_destroy_ioend(). In my kernel (3.18.19), the xfs_destroy_ioend() is [1]. I think it doesn't suffer from the problem of xfs_finish_page_writeback(). Looking at other usage of "b_this_page" in my kernel, they all seem valid, and similar to what Linus's tree has.

Looking at b_private usage to link buffer heads, the only suspicious code is in xfs_submit_ioend():

       for (bh = ioend->io_buffer_head; bh; bh = bh->b_private) {

           if (!bio) {
retry:
               bio = xfs_alloc_ioend_bio(bh);
           } else if (bh->b_blocknr != lastblock + 1) {
               xfs_submit_ioend_bio(wbc, ioend, bio);
               goto retry;
           }

           if (xfs_bio_add_buffer(bio, bh) != bh->b_size) {
               xfs_submit_ioend_bio(wbc, ioend, bio);
               goto retry;
           }

           lastblock = bh->b_blocknr;
       }

Can it happen that when the for loop does "bh = bh->b_private", the bh has already been completed and freed? With this in mind, the "goto retry" also seem suspicious for the same reason.

What do you think?

Thanks,
Alex.

[1]
STATIC void
xfs_destroy_ioend(
   xfs_ioend_t        *ioend)
{
   struct buffer_head    *bh, *next;

   for (bh = ioend->io_buffer_head; bh; bh = next) {
       next = bh->b_private;
       bh->b_end_io(bh, !ioend->io_error);
   }

   mempool_free(ioend, xfs_ioend_pool);
}


-----Original Message----- From: Holger Hoffstätte
Sent: Monday, July 18, 2016 11:18 PM
To: Alex Lyakas ; xfs@xxxxxxxxxxx
Subject: Re: xfs_vm_releasepage() causing BUG at free_buffer_head()

On 07/18/16 20:00, Alex Lyakas wrote:
Greetings XFS community,

We have hit the following BUG [1].

This is in free_buffer_head():
BUG_ON(!list_empty(&bh->b_assoc_buffers));

This is happening in a long-term mainline kernel 3.18.19.

Some googling revealed a possibly-related discussion at:
http://comments.gmane.org/gmane.linux.file-systems/105093
https://lkml.org/lkml/2016/5/30/1007
except that in our case I don't see the "WARN_ON_ONCE(delalloc)" triggered.

Since you make it past the WARN_ONs that makes it look like this
very recent report from Friday:

http://oss.sgi.com/pipermail/xfs/2016-July/050199.html

Dave posted a patch in that thread which seems ot work fine and so
far hasn't set anything on fire, at least for me on 4.4.x.

cheers,
Holger

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs




[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux