8:13 p.m.
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.
Lianbo
+int
+folio_order(ulong folio)
+{
+ ulong v = 0;
+ int PG_head = 16;
+
+ if (THIS_KERNEL_VERSION < LINUX(5,17,0))
+ return 0;
+
+ if (THIS_KERNEL_VERSION < LINUX(6,1,0)) {
+ readmem(folio + OFFSET(page_flags), KVADDR, &v, sizeof(ulong),
+ "folio.page.flags", FAULT_ON_ERROR);
+ if (!(v & (1 << PG_head)))
+ return 0;
+
+ readmem(folio + SIZE(page) + OFFSET(page_compound_order), KVADDR, &v,
+ SIZE(page_compound_order), "page[1].compound_order", FAULT_ON_ERROR);
+
+ return v;
+ } else if (THIS_KERNEL_VERSION < LINUX(6,6,0)) {
+ readmem(folio + OFFSET(page_flags), KVADDR, &v, sizeof(ulong),
+ "folio.page.flags", FAULT_ON_ERROR);
+ if (!(v & (1 << PG_head)))
+ return 0;
+
+ readmem(folio + OFFSET(folio__folio_order), KVADDR, &v,
+ SIZE(folio__folio_order), "folio->_folio_order", FAULT_ON_ERROR);
+
+ return v;
+ } else {
+ /* The PG_head changes to bit 6 at kernel v6.6 */
+ PG_head = 6;
+
+ readmem(folio + OFFSET(page_flags), KVADDR, &v, sizeof(ulong),
+ "folio.page.flags", FAULT_ON_ERROR);
+ if (!(v & (1 << PG_head)))
+ return 0;
+
+ readmem(folio + OFFSET(folio__flags_1), KVADDR, &v,
+ SIZE(folio__flags_1), "folio->_flags_1", FAULT_ON_ERROR);
+
+ return v & 0xff;
+ }
+}
+
#ifdef NOT_USED
ulong
slab_to_kmem_cache_node(struct meminfo *si, ulong slab_page)
diff --git a/symbols.c b/symbols.c
index e6865ca..08c07e9 100644
--- a/symbols.c
+++ b/symbols.c
@@ -10451,6 +10451,9 @@ dump_offset_table(char *spec, ulong makestruct)
fprintf(fp, " page_private: %ld\n",
OFFSET(page_private));
fprintf(fp, " page_page_type: %ld\n",
OFFSET(page_page_type));
+ fprintf(fp, " page_compound_order: %ld\n",
OFFSET(page_compound_order));
+ fprintf(fp, " folio__folio_order: %ld\n",
OFFSET(folio__folio_order));
+ fprintf(fp, " folio__flags_1: %ld\n",
OFFSET(folio__flags_1));
fprintf(fp, " trace_print_flags_mask: %ld\n",
OFFSET(trace_print_flags_mask));
@@ -11961,6 +11964,9 @@ dump_offset_table(char *spec, ulong makestruct)
fprintf(fp, "\n size_table:\n");
fprintf(fp, " page: %ld\n", SIZE(page));
fprintf(fp, " page_flags: %ld\n", SIZE(page_flags));
+ fprintf(fp, " page_compound_order: %ld\n",
SIZE(page_compound_order));
+ fprintf(fp, " folio__folio_order: %ld\n",
SIZE(folio__folio_order));
+ fprintf(fp, " folio__flags_1: %ld\n", SIZE(folio__flags_1));
fprintf(fp, " trace_print_flags: %ld\n",
SIZE(trace_print_flags));
fprintf(fp, " free_area_struct: %ld\n",
SIZE(free_area_struct));
-- 2.43.0
8:53 p.m.
New subject: [PATCH v5 3/5] add folio_order function
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?
Thanks
Huang Shijie
9:59 p.m.
New subject: [PATCH v5 3/5] add folio_order function
On 3/24/26 9:53 AM, Huang Shijie wrote:
>> +/*
>> + * 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?
Not sure, but probably that can be handled based on the above clues(not
rely on kernel version).
Please let me try later(working on other tasks, need some time).
Lianbo
Thanks
Huang Shijie
10:10 p.m.
New subject: [PATCH v5 3/5] add folio_order function
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'm thinking of, for single kernel patch like "mm: reimplement
folio_order() and folio_nr_pages()" or "mm: free up a word in the
first tail page", there isn't obvious enum/structure/member changing
we can take use of. But these patches belongs to a bigger patchsets,
and for patch backporting, we usually won't just backport one, but
backport the whole patchset, so maybe we can take use of this. E.g.
for "mm: reimplement folio_order() and folio_nr_pages()", it belongs
to patchset "MM folio changes for 6.1 [1]", which contains a patch
"mm: Add the first tail page to struct folio" which made a enum
change(enum page_references -> enum folio_references), maybe we can
use this enum change as an indicator for the patchset integration?
Same as other checks as long as we choose the indicator carefully.
BTW, I'm not in favor of integrating so many "kernel history" into
crash utility. By looking at the kernel log for the folio_order()
changing($ git log -L :folio_order:include/linux/mm.h), it looks the
code is unstable and changes every year since 2021. It might get
modified later, who knows... And it will be a burden for crash
maintenance. Maybe a crash extension is better for features like this,
any idea?
Thanks,
Tao Liu
[1]:
https://lore.kernel.org/all/20220902194653.1739778-4-willy@infradead.org/...
Thanks
Huang Shijie
--
Crash-utility mailing list -- devel(a)lists.crash-utility.osci.io
To unsubscribe send an email to devel-leave(a)lists.crash-utility.osci.io
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
10:25 p.m.
New subject: [PATCH v5 3/5] add folio_order function
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.
Thanks
Huang Shijie
10:49 p.m.
New subject: [PATCH v5 3/5] add folio_order function
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
6:35 p.m.
New subject: [PATCH v5 3/5] add folio_order function
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
>
10:15 p.m.
New subject: [PATCH v5 3/5] add folio_order function
On Tue, May 05, 2026 at 11:35:06AM +1200, Tao Liu wrote:
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.
Okay, no problem.
I can follow this method.
Thanks
Huang Shijie
171
days inactive
214
days old
devel@lists.crash-utility.osci.io
7 comments
3 participants
participants (3)
-
Huang Shijie -
Lianbo Jiang -
Tao Liu