Re: [PATCH] error-injection: Add prompt for function error injection

Jiri Kosina
2022-12-02T01:03:13Z

On Thu, 1 Dec 2022, Linus Torvalds wrote:

> > Anyway, I believe [1] that ERROR_INJECTION has been designed as a
> > debugging feature in the first place, and should stay so. After figuring
> > out now that HID-BPF actually has hard dependence on it, I fully agree [2]
> > that the series should be ditched for 6.2 and will work with Benjamin to
> > have it removed from current hid.git#for-next.
>
> I do think that it is interesting to have a "let's have a bpf
> insertion hook here", so I'm not against the _concept_ of HID doing
> that.

Absolutely, me neither, quite the contrary -- I am quite happy to see
HID-BPF happening, because it'll actually make life easier for everybody:
for people with quirky hardware (trivial testing of fixes), for kernel
developers (trivial testing of fixes), and for distributions (trivial
distribution of fixes).

> It's not so different from user-mode drivers, after all, which we also
> have. A kind of half-way state where we have a kernel driver, but one
> that may need custom site-specific (or machine-specific) tweaks.

Indeed. The whole rationale from Benjamin, explaining quite nicely why
HID-BPF is a good thing, can be found in the very original, initial
ancient cover letter:

https://lore.kernel.org/lkml/20220224110828.2168231-1-benjamin.tissoires@redhat.com/

> So I don't want to come across as being against having bpf used for
> tuning some HID issue (and I can imagine it making sense in other places
> that have machine-specific tweaks - I'm thinking of all the thermal
> probe or pincontrol mess where sometimes you have GPIO's or motherboard
> thermal sensors etc that are literally "user connected it to X").
>
> But the notion that we'd use some error injection framework for it,
> and that you'd mix those concepts up - *that* I really think is just
> horrendous.

Fully agreed. I unfortunately missed that particular aspect during review,
and it popped up only after HID-BPF appeared in linux-next.

--
Jiri Kosina
SUSE Labs