[Crash-utility] Re: [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&gt; 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&lt;huangsj(a)hygon.cn&gt; > > > 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&lt;huangsj(a)hygon.cn&gt; > > > 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&lt;huangsj(a)hygon.cn&gt; > > > --- > > > 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.