Re: xfs_vm_releasepage() causing BUG at free_buffer_head()

["Alex Lyakas" <alex@xxxxxxxxxxxxxxxxx>]

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