On Mon, 2020-05-18 at 19:59 +0000, Luis Chamberlain wrote:
quoted
Err, no. Those two are most definitely related. Have you looked at (most
or some or whatever) staging drivers recently? Those contain all kinds
of garbage that might do whatever with your kernel.
No, I stay away :)
:)
quoted
That's all fine, I just don't think it's appropriate to pretend that
your kernel is now 'tainted' (think about the meaning of that word) when
the firmware of some random device crashed.
If the firmware crash *does* require driver remove / addition again,
or a reboot, would you think that this is a situation that merits a taint?
Not really. In my experience, that's more likely a hardware issue (card
not properly seated, for example) that a bus reset happens to "fix".
quoted
It's pretty clear, but even then, first of all I doubt this is the case
for many of the places that you've sprinkled the annotation on,
We can remove it, for this driver I can vouch for its location as it did
reach a state where I required a reboot. And its not the first time this
has happened. This got me thinking about the bigger picture of the lack
of proper way to address these cases in the kernel, and how the user is
left dumbfounded.
Fair, so the driver is still broken wrt. recovery here. I still don't
think that's a situation where e.g. the system should say "hey you have
a taint here, if your graphics go bad now you should not report that
bug" (which is effectively what the single taint bit does).
quoted
and secondly it actually hides useful information.
What is it hiding?
Most importantly, which device crashed. Secondarily I'd say how many
times (*).
The information "firmware crashed" is really only useful in relation to
the device. If your graphics firmware crashed, yeah, well, you probably
won't even see this. If your USB wifi firmware crashed? Not really
interesting, you'll anyway just unplug. In fact it's very hard for a USB
driver (short of arbitrary memory corruption) to significantly mess up
the system.
johannes
(*) though if it crashed only once, was that because it was wedged
enough to be unusable afterwards, or because everything was fine?
On Mon, May 18, 2020 at 10:07:49PM +0200, Johannes Berg wrote:
On Mon, 2020-05-18 at 19:59 +0000, Luis Chamberlain wrote:
quoted
quoted
Err, no. Those two are most definitely related. Have you looked at (most
or some or whatever) staging drivers recently? Those contain all kinds
of garbage that might do whatever with your kernel.
No, I stay away :)
:)
quoted
quoted
That's all fine, I just don't think it's appropriate to pretend that
your kernel is now 'tainted' (think about the meaning of that word) when
the firmware of some random device crashed.
If the firmware crash *does* require driver remove / addition again,
or a reboot, would you think that this is a situation that merits a taint?
Not really. In my experience, that's more likely a hardware issue (card
not properly seated, for example) that a bus reset happens to "fix".
quoted
quoted
It's pretty clear, but even then, first of all I doubt this is the case
for many of the places that you've sprinkled the annotation on,
We can remove it, for this driver I can vouch for its location as it did
reach a state where I required a reboot. And its not the first time this
has happened. This got me thinking about the bigger picture of the lack
of proper way to address these cases in the kernel, and how the user is
left dumbfounded.
Fair, so the driver is still broken wrt. recovery here. I still don't
think that's a situation where e.g. the system should say "hey you have
a taint here, if your graphics go bad now you should not report that
bug" (which is effectively what the single taint bit does).
But again, let's think about the generic type of issue, and the
unexpected type of state that can be reached. The circumstance here
*does* lead to a case which is not recoverable. Now, consider how
many cases in the kernel where similar situations can happen and leave
the device or driver in a non-functional state.
quoted
quoted
and secondly it actually hides useful information.
What is it hiding?
Most importantly, which device crashed. Secondarily I'd say how many
times (*).
The device is implied by the module, the taint is applied to both.
If you had multiple devices, however, yes, it would not be possible
to distinguish from the taint which exact device it happened on.
So the only thing *generic* which would be left out is count.
The information "firmware crashed" is really only useful in relation to
the device.
If you have to reboot to get a functional network again then the device
is quite useless for many people, regardless of which device that
happened on.
But from a support perspective a sysfs interface which provides a tiny
bit more generic information indeed provides more value than a taint.
Luis