Hi Huang,
Lianbo may be unavailable for the time being, and sorry for my late
response. I have rethought your patchset. Please see my comments:
For this patch, I still think the THIS_KERNEL_VERSION() macro isn't a
good choice, and I have made my point in the previous discussion.
To illustrate my approach:
Linux source $ git log -L :folio_order:include/linux/mm.h
...
mm: free up a word in the first tail page
mm: reimplement folio_order() and folio_nr_pages()
mm: Add folio_test_pmd_mappable()
Each kernel commit represents an update to folio_order() that you'd
like to backport to crash. And each one belongs to a parent patchset,
e.g the "mm: Add folio_test_pmd_mappable()" one belongs to patchset
[1], so a struct/enum modification within the patchset can be choose
as an indicator, e.g. struct folio_batch is introduced within this
patchset, this might be a good candidate. BTW, if you do this, please
attach the patchset link with the indicator, so in the future people
will know where the indicator was chosen from, to improve
maintainability.
Thanks,
Tao Liu
[1]:
https://lore.kernel.org/all/20211208042256.1923824-1-willy@infradead.org/
}
}
On Tue, Mar 24, 2026 at 4:49 PM Tao Liu <ltao(a)redhat.com> wrote:
On Tue, Mar 24, 2026 at 4:26 PM Huang Shijie <huangsj(a)hygon.cn> wrote:
>
> On Tue, Mar 24, 2026 at 04:10:26PM +1300, Tao Liu wrote:
> > Hi Huang,
> >
> > On Tue, Mar 24, 2026 at 2:55 PM Huang Shijie <huangsj(a)hygon.cn> wrote:
> > >
> > > On Tue, Mar 24, 2026 at 09:13:33AM +0800, Lianbo Jiang wrote:
> > > > On 3/18/26 8:24 PM, devel-request(a)lists.crash-utility.osci.io wrote:
> > > >
> > > > > Date: Wed, 18 Mar 2026 20:23:38 +0800
> > > > > From: Huang Shijie<huangsj(a)hygon.cn>
> > > > > Subject: [Crash-utility] [PATCH v5 3/5] add folio_order
function
> > > > >
To:<ltao@redhat.com>,<k-hagio-ab@nec.com>,<lijiang@redhat.com>
> > > > > Cc:devel@lists.crash-utility.osci.io,zhongyuan@hygon.cn,
> > > > > fangbaoshun@hygon.cn,yingzhiwei@hygon.cn,1537577747(a)qq.com,
Huang
> > > > > Shijie<huangsj(a)hygon.cn>
> > > > > Message-ID:<20260318122340.53291-4-huangsj@hygon.cn>
> > > > > Content-Type: text/plain
> > > > >
> > > > > The folio_order() was introduced to kernel at v5.16, but the
first
> > > > > large folio support patch is in v5.17:
> > > > > 6795801366da "xfs: Support large folios"
> > > > >
> > > > > The folio_order() keeps the same logic as kernel code
> > > > > in different versions:
> > > > > 1.) In kernel v5.17, folio_order() uses
page[1].compound_order to
> > > > > get the folio order.
> > > > >
> > > > > 2.) In kernel v6.1, the following patch introduces
_folio_order:
> > > > > c3a15bff46cb5149 "mm: reimplement folio_order() and
folio_nr_pages()"
> > > > >
> > > > > folio_order() uses _folio_order to get the folio order.
> > > > >
> > > > > 3.) In kernel v6.6, the following patch replaces the
_folio_order with _flags_1:
> > > > > ebc1baf5c9b46c22 "mm: free up a word in the first
tail page"
> > > > >
> > > > > folio_order() uses _flags_1 to get the folio order.
> > > > >
> > > > > This patch will be used in later patches.
> > > > >
> > > > > Signed-off-by: Huang Shijie<huangsj(a)hygon.cn>
> > > > > ---
> > > > > defs.h | 8 +++++++
> > > > > memory.c | 70
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > > > symbols.c | 6 +++++
> > > > > 3 files changed, 84 insertions(+)
> > > > >
> > > > > diff --git a/defs.h b/defs.h
> > > > > index 8f6784e..e832ea6 100644
> > > > > --- a/defs.h
> > > > > +++ b/defs.h
> > > > > @@ -2290,6 +2290,9 @@ struct offset_table {
/* stash of commonly-used offsets */
> > > > > long bpf_ringbuf_nr_pages;
> > > > > long hrtimer_clock_base_index;
> > > > > long klp_patch_list;
> > > > > + long page_compound_order;
> > > > > + long folio__folio_order;
> > > > > + long folio__flags_1;
> > > > > };
> > > > > struct size_table { /* stash of commonly-used sizes
*/
> > > > > @@ -2469,6 +2472,9 @@ struct size_table { /* stash of
commonly-used sizes */
> > > > > long cpumask_t;
> > > > > long task_struct_exit_state;
> > > > > long bpf_ringbuf_map;
> > > > > + long page_compound_order;
> > > > > + long folio__folio_order;
> > > > > + long folio__flags_1;
> > > > > };
> > > > > struct array_table {
> > > > > @@ -6008,6 +6014,8 @@ ulong do_xarray(ulong, int, struct
list_pair *, int);
> > > > > #define XARRAY_TAG_MASK (3UL)
> > > > > #define XARRAY_TAG_INTERNAL (2UL)
> > > > > +int folio_order(ulong folio);
> > > > > +
> > > > > int file_dump(ulong, ulong, ulong, int, int);
> > > > > #define DUMP_FULL_NAME 0x1
> > > > > #define DUMP_INODE_ONLY 0x2
> > > > > diff --git a/memory.c b/memory.c
> > > > > index 17423a5..3b272ad 100644
> > > > > --- a/memory.c
> > > > > +++ b/memory.c
> > > > > @@ -547,6 +547,13 @@ vm_init(void)
> > > > > MEMBER_OFFSET_INIT(page_freelist, "page",
"freelist");
> > > > > MEMBER_OFFSET_INIT(page_page_type, "page",
"page_type");
> > > > > + MEMBER_OFFSET_INIT(page_compound_order, "page",
"compound_order");
> > > > > + MEMBER_SIZE_INIT(page_compound_order, "page",
"compound_order");
> > > > > + MEMBER_OFFSET_INIT(folio__folio_order, "folio",
"_folio_order");
> > > > > + MEMBER_SIZE_INIT(folio__folio_order, "folio",
"_folio_order");
> > > > > + MEMBER_OFFSET_INIT(folio__flags_1, "folio",
"_flags_1");
> > > > > + MEMBER_SIZE_INIT(folio__flags_1, "folio",
"_flags_1");
> > > > > +
> > > > > MEMBER_OFFSET_INIT(mm_struct_pgd, "mm_struct",
"pgd");
> > > > > MEMBER_OFFSET_INIT(swap_info_struct_swap_file,
> > > > > @@ -20426,6 +20433,69 @@ static unsigned int oo_objects(ulong
oo)
> > > > > return (oo & ((1 << 16) - 1));
> > > > > }
> > > > > +/*
> > > > > + * The folio_order() was introduced to kernel at v5.16, but the
first
> > > > > + * large folio support patch is in v5.17:
> > > > > + * 6795801366da "xfs: Support large folios"
> > > > > + *
> > > > > + * 1.) In kernel v5.17, folio_order() uses
page[1].compound_order to
> > > > > + * get the folio order.
> > > > > + *
> > > > > + * 2.) In kernel v6.1, the following patch introduces
_folio_order:
> > > > > + * c3a15bff46cb5149 "mm: reimplement folio_order()
and folio_nr_pages()"
> > > > > + *
> > > > > + * folio_order() uses _folio_order to get the folio
order.
> > > > > + *
> > > > > + * 3.) In kernel v6.6, the following patch replaces the
_folio_order with _flags_1:
> > > > > + * ebc1baf5c9b46c22 "mm: free up a word in the first
tail page"
> > > > > + *
> > > > > + * folio_order() uses _flags_1 to get the folio order.
> > > > > + */
> > > >
> > > > For this check condition, It's not very good to use kernel
version. Let's
> > > > investigate if there is a better way to handle this issue.
> > > Do you have any better idea about it?
> >
> > The kernel version checks as THIS_KERNEL_VERSION < LINUX(6,6,0) is not
> > a good option. The linux distros are likely to backport the upstream
> > patches to a lower version, making the patch which is meant for
> > LINUX(6,6,0) upstream to be avaliable within LINUX(5,17,0) rhel or
> > else. The THIS_KERNEL_VERSION() check should only be used when there
> > is no other alternatives. Datatype changing like enum/structure/member
> > existence checking are better options.
> I am okay with this method.
>
> If we all like this method, I can change the code.
Let's wait for @lianbo's idea.
Thanks,
Tao Liu
>
> Thanks
> Huang Shijie
>