On Tue, Jul 22, 2025 at 3:28 PM David Hildenbrand <david@xxxxxxxxxx> wrote: > > On 22.07.25 04:40, Yafang Shao wrote: > > On Sun, Jul 20, 2025 at 11:56 PM David Hildenbrand <david@xxxxxxxxxx> wrote: > >> > >>>> > >>>> We discussed this yesterday at a THP upstream meeting, and what we > >>>> should look into is: > >>>> > >>>> (1) Having a callback like > >>>> > >>>> unsigned int (*get_suggested_order)(.., bool in_pagefault); > >>> > >>> This interface meets our needs precisely, enabling allocation orders > >>> of either 0 or 9 as required by our workloads. > >>> > >>>> > >>>> Where we can provide some information about the fault (vma > >>>> size/flags/anon_name), and whether we are in the page fault (or in > >>>> khugepaged). > >>>> > >>>> Maybe we want a bitmap of orders to try (fallback), not sure yet. > >>>> > >>>> (2) Having some way to tag these callbacks as "this is absolutely > >>>> unstable for now and can be changed as we please.". > >>> > >>> BPF has already helped us complete this, so we don’t need to implement > >>> this restriction. > >>> Note that all BPF kfuncs (including struct_ops) are currently unstable > >>> and may change in the future. > >> > > Alexei, could you confirm this understanding? > >> > >> Every MM person I talked to about this was like "as soon as it's > >> actively used out there (e.g., a distro supports it), there is no way > >> you can easily change these callbacks ever again - it will just silently > >> become stable." > >> > >> That is actually the biggest concern from the MM side: being stuck with > >> an interface that was promised to be "unstable" but suddenly it's > >> not-so-unstable anymore, and we have to support something that is very > >> likely to be changed in the future. > >> > >> Which guarantees do we have in the regard? > >> > >> How can we make it clear to anybody using this specific interface that > >> "if you depend on this being stable, you should learn how to read and > >> you are to blame, not the MM people" ? > > > > As explained in the kernel document [0]: > > > > kfuncs provide a kernel <-> kernel API, and thus are not bound by any > > of the strict stability restrictions associated with kernel <-> user > > UAPIs. This means they can be thought of as similar to > > EXPORT_SYMBOL_GPL, and can therefore be modified or removed by a > > maintainer of the subsystem they’re defined in when it’s deemed > > necessary. > > > > [0] https://docs.kernel.org/bpf/kfuncs.html#bpf-kfunc-lifecycle-expectations > > > > That said, users of BPF kfuncs should treat them as inherently > > unstable and take responsibility for verifying their compatibility > > when switching kernel versions. However, this does not imply that BPF > > kfuncs can be modified arbitrarily. > > > > For widely adopted kfuncs that deliver substantial value, changes > > should be made cautiously—preferably through backward-compatible > > extensions to ensure continued functionality across new kernel > > versions. Removal should only be considered in exceptional cases, such > > as: > > - Severe, unfixable issues within the kernel > > - Maintenance burdens that block new features or critical improvements. > > And that is exactly what we are worried about. > > You don't know beforehand whether something will be "widely adopted". > > Even if there is the "A kfunc will never have any hard stability > guarantees." in there. > > The concerning bit is: > > "kfuncs that are widely used or have been in the kernel for a long time > will be more difficult to justify being changed or removed by a > maintainer. " > > Just no. Not going to happen for the kfuncs we know upfront (like here) > will stand in our way in the future at some point and *will* be changed > one way or another. > > > So for these kfuncs I want a clear way of expressing "whatever the > kfuncs doc says, this here is completely unstable even if widely used" This statement does not conflict with the BPF kfuncs documentation, as it explicitly states: "This means they can be thought of as similar to EXPORT_SYMBOL_GPL, and can therefore be modified or removed by a maintainer of the subsystem they're defined in when deemed necessary." There is no question that subsystem maintainers have the authority to remove kfuncs. However, the reason I raised the issue of removing widely used kfuncs is to highlight the recommended practice: - First mark the kfunc as KF_DEPRECATED. - Remove it in the next development cycle. While this is not a strict requirement—maintainers can remove kfuncs immediately without deprecation—following this guideline helps avoid unnecessary disruptions for users. -- Regards Yafang
