Re: [RFC PATCH v3 0/5] mm, bpf: BPF based THP adjustment

[Yafang Shao <laoar.shao@gmail.com>]

On Tue, Jul 22, 2025 at 7:55 PM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> On Tue, Jul 22, 2025 at 07:46:57PM +0800, Yafang Shao wrote:
> > > 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."
>
> Except that's not how EXPORT_SYMBOL_GPL() works at all, we can remove at
> will and are only required to update in-kernel users.
>
> So that comparison is simply bogus.
>
> >
> > There is no question that subsystem maintainers have the authority to
> > remove kfuncs. However, the reason I raised the issue of removing
>
> Except the documentation that seems to very strongly suggest otherwise?
>
> > widely used kfuncs is to highlight the recommended practice:
> > - First mark the kfunc as KF_DEPRECATED.
> > - Remove it in the next development cycle.
>
> This seems reasonable, but I'm not in the slightest confident in us just
> relying on this.
>
> >
> > While this is not a strict requirement—maintainers can remove kfuncs
> > immediately without deprecation—following this guideline helps avoid
> > unnecessary disruptions for users.
>
> The documentation doesn't state this, you are surely just inferring it?

As noted in the other thread, the maintainers ultimately have final
say on this matter. I'm simply sharing my perspective here.

>
> >
> > --
> > Regards
> > Yafang
>
> Overall I think we need a different mechanism in addition to this, such as
> a very clearly described CONFIG_ option that makes it ABUNDANTLY clear that
> the config and thus the related BPF hook may be removed at any time.
>
> Ideally with 'experimental' or such in the name, or perhaps even tainting
> the kernel.

Agreed.

>
> We definitely need something better than what this documentation is saying,
> sorry. I am not in any way confident in relying no what this document
> states.

The documentation has always been difficult to understand ;-)

-- 
Regards
Yafang