Risks

Posted Sep 30, 2025 10:30 UTC (Tue) by patrakov (subscriber, #97174)
Parent article: Bcachefs removed from the mainline kernel

Before Bcachefs getting mainlined, one had to get the whole kernel source tree from the Bcachefs author. This happened because this filesystem relied on changes in other subsystems, and was not just a self-contained add-on. Upon upstreaming, the required changes were applied to these subsystems, making Bcachefs self-contained, and then it was split out as a module that can be compiled via DKMS.

Here I see the risk of the mainline kernel reverting the changes in other subsystems, because they might no longer have an in-tree user. Am I paranoid? What's the Bcachefs project's position on this risk if it is material - are they going to adapt, or go back to telling the user to compile their tree, as opposed to compiling just their module against an existing kernel?

Risks

Posted Sep 30, 2025 16:45 UTC (Tue) by georgh-cat (guest, #158897) [Link]

That's exactly my thought as well, and the kind of conversation that is impossible in phoronix (but it should)

Risks

Posted Oct 1, 2025 1:07 UTC (Wed) by neilbrown (subscriber, #359) [Link] (1 responses)

As a concrete example, there are now no in-kernel users for start_removing_user_path_at() (recently renamed from user_path_locked_at()).
I wonder how long until someone decides to remove that because there are no users.

Risks

Posted Oct 2, 2025 12:34 UTC (Thu) by aakef (subscriber, #38030) [Link]

It is a bit sad, adding a bcachefs-updates dkms module with features that would appear in the next kernel version would have been simple. I.e. the entire _final_ way to upset Linus and everyone else in kernel community was absolutely not needed. Bcachefs could have stayed in kernel and bcachefs-updates could had all the features/fixes that upstream thought is required. And no issue with functions/exports that might get removed now.

Risks

Posted Oct 1, 2025 10:08 UTC (Wed) by tux3 (subscriber, #101245) [Link] (2 responses)

Well, there is precedent there, so I wouldn't be entirely surprised.

ZFS's compatibility layer used to call kallsyms_lookup_name (years before that was unexported).
They managed to remove all uses of it, although my slightly caricaturistic view of ZFS is that of a monolith that transcends all layer boundaries and is more than happy to implement their own deeply integrated features (ARC, etc) instead of importing an existing interface. That's not how I see bcachefs, although it does have plenty of integrated features.

And sometimes it's not an option. Systemtap wouldn't be viable if it could only lookup exported symbols, so they hack around it with the kernel text base and relocations:
> We do this under protest. The kernel ought expose this data to
> modules such as ourselves, but instead the upstream community
> continually shrinks its module-facing interfaces, including this
> stuff, even when users exist.
> PR26074: as of kernel 5.7+ / commit 0bd476e6c671 and under further
> protest, we must also send the address of kallsyms_lookup_name and
> kallsyms_for_each_symbol.

Hard to predict whether bcachefs will be given the "ZFS treatment", but I imagine there's three paths in response.
Try to workaround the missing symbol, go back in tree, or fight a cat-and-mouse game to keep DKMS.

systemtap kallsyms_lookup_name

Posted Oct 1, 2025 21:47 UTC (Wed) by gioele (subscriber, #61675) [Link] (1 responses)

> And sometimes it's not an option. Systemtap wouldn't be viable if it could only lookup exported symbols, so they hack around it with the kernel text base and relocations:
>> We do this under protest. The kernel ought expose this data to
>> modules such as ourselves, but instead the upstream community
>> continually shrinks its module-facing interfaces, including this
>> stuff, even when users exist.
>> PR26074: as of kernel 5.7+ / commit 0bd476e6c671 and under further
>> protest, we must also send the address of kallsyms_lookup_name and
>> kallsyms_for_each_symbol.

In case anybody is wondering where this text comes from (I could not find any references to this passage via Google Search or DuckDuckGo), it is from `[systemtap]/staprun/staprun.c` (<https://sourceware.org/git/?p=systemtap.git;a=blob;f=stap...>). The PR mentioned in the comment can be seen at <https://sourceware.org/git/?p=systemtap.git;a=commit;h=1e...>.

systemtap kallsyms_lookup_name

Posted Oct 3, 2025 10:11 UTC (Fri) by ferringb (subscriber, #20752) [Link]

System tap wasn't causative, but zfs presumably was. https://lwn.net/Articles/813350/ . If you're non GPL but using a side door to access symbols that are GPL limited... Etc.