On Mon, Sep 8, 2025 at 2:23 PM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > On Mon, 2025-09-08 at 14:21 +0100, Mykyta Yatsenko wrote: > > On 9/8/25 08:43, Eduard Zingerman wrote: > > > On Fri, 2025-09-05 at 17:45 +0100, Mykyta Yatsenko wrote: > > > > From: Mykyta Yatsenko <yatsenko@xxxxxxxx> > > > > > > > > Introducing selftests that check BPF task work scheduling mechanism. > > > > Validate that verifier does not accepts incorrect calls to > > > > bpf_task_work_schedule kfunc. > > > > > > > > Signed-off-by: Mykyta Yatsenko <yatsenko@xxxxxxxx> > > > > --- > > > The test cases in this patch check functional correctness, but there > > > is no attempt to do some stress testing of the state machine. > > > E.g. how hard/feasible would it be to construct a test that attempts > > > to exercise both branches of the (state == BPF_TW_SCHEDULED) in the > > > bpf_task_work_cancel_and_free()? > > > Good point, I have stress test, but did not include it in the patches, > > as it takes longer to run. > > I had to add logs in the kernel code to make sure cancellation/freeing > > branches are hit. > > https://github.com/kernel-patches/bpf/commit/86408b074ab0a2d290977846c3e99a07443ac604 > > Ack. I see no harm in having such test run for a couple of seconds on > CI, but up to you. Well, we generally push back against long running tests. We have tons of them and maintainers still often run all of the tests locally (and even with -j parallelization they run sloooowww), so I'd avoid adding a test that will run for a few seconds hoping to trigger some unlikely condition.
