Re: [PATCH 7/8] gfs2: Convert gfs2_end_log_write_bh() to work on a folio

[Matthew Wilcox <willy@infradead.org>]

On Sun, Mar 09, 2025 at 10:53:29PM +0100, Andreas Gruenbacher wrote:
> On Sun, Mar 9, 2025 at 9:57 PM Matthew Wilcox <willy@infradead.org> wrote:
> > On Sun, Mar 09, 2025 at 06:33:34PM +0100, Andreas Gruenbacher wrote:
> > > On Mon, Feb 10, 2025 at 2:35 PM Matthew Wilcox (Oracle)
> > > <willy@infradead.org> wrote:
> > > > gfs2_end_log_write() has to handle bios which consist of both pages
> > > > which belong to folios and pages which were allocated from a mempool and
> > > > do not belong to a folio.  It would be cleaner to have separate endio
> > > > handlers which handle each type, but it's not clear to me whether that's
> > > > even possible.
> > > >
> > > > This patch is slightly forward-looking in that page_folio() cannot
> > > > currently return NULL, but it will return NULL in the future for pages
> > > > which do not belong to a folio.
> > > >
> > > > This was the last user of page_has_buffers(), so remove it.
> > >
> > > Right now in for-next, ocfs2 is still using page_has_buffers(), so I'm
> > > going to skip this part.
> >
> > How odd.  I see it removed in 1b426db11ba8 ecee61651d8f 0fad0a824e5c
> > 414ae0a44033 and all of those commits are in 6.14-rc1.
> >
> > $ git show v6.14-rc1:fs/ocfs2/aops.c |grep page_has
> > (no output)
> 
> Hmm, you're right, it's only that automatic test that's based on an
> older kernel. Sorry for the confusion.

Looks like your for-next doesn't include v6.14-rc1.

gfs2            104b4d597ff21b923b1e963c5793efcadeae047e

is the entry in SHA1s for next-20250307.  And:

$ git log v6.14-rc1 ^104b4d597ff21b923b1e963c5793efcadeae047e
shows quite a lot of commits (9847 of them).  So I think you didn't pull
from Linus before branching for the v6.15 merge window.  Not sure how
you manage your trees and how you'd like to improce this situation
(do you rebase?  Do you want to bring in a merge commit of some -rc
version?  If so, which one?)