linux-kernel - Re: [RFC][PATCH 1/4] mm, page_owner: add folio allocate post callback for struct page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEr6+EB5q3ksmgYruOVngiwf6KJcrzABchd=Osyk0MiVDGQyQQ@mail.gmail.com>
Date:   Thu, 9 Nov 2023 23:25:18 +0800
From:   Jeff Xie <xiehuan09@...il.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Jeff Xie <jeff.xie@...ux.dev>, akpm@...ux-foundation.org,
        iamjoonsoo.kim@....com, vbabka@...e.cz, cl@...ux.com,
        penberg@...nel.org, rientjes@...gle.com, roman.gushchin@...ux.dev,
        42.hyeyoo@...il.com, linux-mm@...ck.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        chensong_2000@....cn
Subject: Re: [RFC][PATCH 1/4] mm, page_owner: add folio allocate post callback
 for struct page_owner to make the owner clearer

Hi Matthew,

On Thu, Nov 9, 2023 at 10:00 PM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Thu, Nov 09, 2023 at 11:25:18AM +0800, Jeff Xie wrote:
> > adding a callback function in the struct page_owner to let the slab layer or the
> > anon/file handler layer or any other memory-allocated layers to implement what
> > they would like to tell.
>
> There's no need to add a callback.  We can tell what a folio is.
>
> > +     if (page_owner->folio_alloc_post_page_owner) {
> > +             rcu_read_lock();
> > +             tsk = find_task_by_pid_ns(page_owner->pid, &init_pid_ns);
> > +             rcu_read_unlock();
> > +             ret += page_owner->folio_alloc_post_page_owner(page_folio(page), tsk, page_owner->data,
> > +                             kbuf + ret, count - ret);
> > +     } else
> > +             ret += scnprintf(kbuf + ret, count - ret, "OTHER_PAGE\n");
>
>         if (folio_test_slab(folio))
>                 ret += slab_page_owner_info(folio, kbuf + ret, count - ret);
>         else if (folio_test_anon(folio))
>                 ret += anon_page_owner_info(folio, kbuf + ret, count - ret);
>         else if (folio_test_movable(folio))
>                 ret += null_page_owner_info(folio, kbuf + ret, count - ret);
>         else if (folio->mapping)
>                 ret += file_page_owner_info(folio, kbuf + ret, count - ret);
>         else
>                 ret += null_page_owner_info(folio, kbuf + ret, count - ret);
>
> In this scenario, I have the anon handling ksm pages, but if that's not
> desirable, we can add
>
>         else if (folio_test_ksm(folio))
>                 ret += ksm_page_owner_info(folio, kbuf + ret, count - ret);
>
> right before the folio_test_anon() clause

Thank you very much for your advice and guidance.
>From the perspective of a folio, it cannot obtain information about
all the situations in which folios are allocated.
If we want to determine whether a folio is related to vmalloc or
kernel_stack or the other memory allocation process,
using just a folio parameter is not sufficient. To achieve this goal,
we can add a callback function to provide more extensibility and
information.

for example:

（the following "OTHER_PAGE" will be replaced with the specified
information later）

 Page allocated via order 0, mask
0x2102(__GFP_HIGHMEM|__GFP_NOWARN|__GFP_ZERO), pid 0, tgid 0
(swapper/0), ts 167618849 ns
OTHER_PAGE
PFN 0x4a92 type Unmovable Block 37 type Unmovable Flags
0x1fffc0000000000(node=0|zone=1|lastcpupid=0x3fff)
 post_alloc_hook+0x77/0xf0
 get_page_from_freelist+0x58d/0x14e0
 __alloc_pages+0x1b2/0x380
 __alloc_pages_bulk+0x39f/0x620
 alloc_pages_bulk_array_mempolicy+0x1f4/0x210
 __vmalloc_node_range+0x756/0x870
 __vmalloc_node+0x48/0x60
 gen_pool_add_owner+0x3e/0xb0
 mce_gen_pool_init+0x5a/0x90
 mcheck_cpu_init+0x170/0x4c0
 identify_cpu+0x55f/0x7e0
 arch_cpu_finalize_init+0x10/0x100
 start_kernel+0x517/0x8e0
 x86_64_start_reservations+0x18/0x30
 x86_64_start_kernel+0xc6/0xe0
 secondary_startup_64_no_verify+0x178/0x17b

-- 
Thanks,
JeffXie