On 19/06/2024 21:12, Eduard Zingerman wrote: > On Wed, 2024-06-19 at 18:42 +0100, Alan Maguire wrote: > > [...] > >> Sorry, I'm not following here. So I think what you'd like is a way to >> verify that the dtor actually runs, is that right? The problem there is >> that the map cleanup gets run when the skeleton gets destroyed, but then >> it's too late then to collect a count value via that BPF object. >> >> The only thing I can think of is to create an additional tracing object >> that we separately load/attach to bpf_testmod_ctx_release() prior to >> running kfunc call tests to verify that the destructor fires on cleanup >> of the kfunc test skeletons. Is that what you have in mind? Thanks! > > Tracing program could be an option, yes. > I was thinking about some map created by the driver program (the one > from prog_tests) that could be updated by destructor. > There is a question of how to pass the map FD to the kfunc, > probably it could be passed in a constructor for the kfunc and stored > in the context. But tracing program sounds good as well. > > Again, it might be the case that checking that registration logic > works is sufficient. In such a case bodies of both kfunc and BPF > program could be empty. > I explored this further. Even adding a separate skeleton with tracing prog to catch release is insufficient because the map free is deferred and the test can have already run by the time the deferred map free is called. Whatever mechanism we use to detect release would be subject to the timing of that it seems. This seems like a recipe for a flaky test and I'd rather not add sleeps etc so I've stuck with the current approach which exercises the dtor codepaths but doesn't verify release. Thanks! Alan
