On Sun, 11 Dec 2022 08:49:01 +0100 KP Singh <kpsingh@xxxxxxxxxx> wrote: > Let's take a step back and focus on solving debuggability and > introspection as we clearly have some perception issues about taints > in the community. (distro maintainers, users) before we go and add > more taints. Note, you will likely get the same push back if the dump includes bpf programs known to change the return of a function that may be involved with the bug report. That is, if a crash is reported to code I maintain, and I see that the bug report includes a list of BPF programs that can modify the return of a function, and one of those functions could affect the place that crashed, I'd push back and ask if the crash could be done without that BPF program loaded, regardless of taints. I agree that a taint is just a hint and it can include something that caused the bug or it may not. I would like to see more details in how the crashed kernel was configured. That includes loaded BPF programs (just like we include loaded modules). And if any BPF program modifies a core function (outside of syscall returns) I'd be a bit suspect of what happened. I also agree that if a function that checks error paths fails, it should be fixed, but knowing that the error path was caused by fault injection will prevent the wasted effort that most developers will go through to find out why the error path was hit in the first place. -- Steve
