On Thu, Jul 17, 2025 at 05:08:11PM +0200, Mikulas Patocka wrote:
> Hi
>
> I wouldn't do this - these sorts of changes will cause problems when
> backporting bugfixes to the stable kernel branches.
>
> Mikulas
Sure, but doing the right thing in mainline takes priority over ease of
backports.
The naming here is challenging, and it is annoying that the UAPIs
"try_verify_in_tasklet" and "use_bh_bytes" are stuck with misleading
names that are tied to obsolete implementation details. But for the
internal names I do think this patch is an improvement. There are 4
cases for how data verification can happen now:
1. In a kworker, via a regular workqueue.
2. (When try_verify_in_tasklet=true)
Inline in verity_end_io() in softirq context. This happens when
verity_end_io() is invoked in the BLOCK_SOFTIRQ.
3. (When try_verify_in_tasklet=true)
Inline in verity_end_io() in task context. This happens when
verity_end_io() is invoked by kworker, e.g. the loop device's.
4. (When try_verify_in_tasklet=true)
In a softirq following verity_end_io(), via the BH workqueue.
This happens when verity_end_io() is invoked in hardirq context.
The name "in_bh" is wrong for case (3). The name "use_bh_wq_enabled" is
wrong for cases (2) and (3).
But "in_bh" really just tracks whether sleeping code paths should be
executed or not. "may_sleep" better reflects that.
For the rest, I think calling (2) through (4) "inline verification"
makes sense. It clearly fits cases (2) and (3). It's somewhat of a
stretch for (4); however, it's still "inline" in the sense that it tends
to happen in the same non-schedulable section as the hardirq itself.
Naming things is hard...
- Eric
