Andrei Măceș

- Would `#ifdef CONFIG_SDFAT_FS_MODULE` be better? - What if we replace `blk_start_plug` with: ``` if (!current->plug) current->plug = &plug; ``` - That should basically equal `blk_flush_plug(current)` across all kernels, w/o...

> What would be the difference using #ifdef CONFIG_SDFAT_FS_MODULE or #ifdef MODULE? It shouldn't make any difference in this case; just thought the full symbol is more explicit. Either way,...

> Seems like the error message is from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/kernel/bpf/verifier.c?h=v6.17.8&id=9325d53fe9adff354b6a93fda5f38c165947da0f#n2585, unrelated to the `WARN_ONCE`s. And yet it chose to return success even with this message, which is confusing. Yeah, based on...

> I happen to find out that a recent patch https://lkml.org/lkml/2025/11/7/1313 could be addressing this issue. I don't have time recently to test the kernel, so appreciated if anyone could...

Same verifier bug with https://lore.kernel.org/bpf/[email protected]/, unfortunately.

That's a proper way to debug this. I can tell you that it started with 6.17 since 6.16.y is fine. It could be related to the SCC changes that happened...

I rebased current `bpf-next` on top of `6.18.0-rc7` plus added https://lore.kernel.org/lkml/[email protected]/ since it looked promising. Alas, the verifier bug is still there.

Cosmetically, this is the reason for the `reg_bounds_sanity_check()` verifier bug being displayed now: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0df1a55afa832f463f9ad68ddc5de92230f1bc8a. However, this `REG INVARIANTS VIOLATION` was likely hit in older kernels too, just hidden away before...