7 ms·

Say there's a minor error in a network driver. Yes, it might be exploitable by a smart person. But the error only triggers once a day when a counter rolls over

Say there's a minor error in a network driver. Yes, it might be exploitable by a smart person. But the error only triggers once a day when a counter rolls over. Do you really want your box to lock up and panic when this error is encountered, or do you just want your box to keep working. I'm firmly in the first camp (I'll take lock up and freeze thanks) but 99% of users don't care about a bug like that and just want the box to keep working.

jbangert 9y ago
But do you want your box to send silently corrupted data for the next two years? Or would you rather reboot every night, and maybe escalate to your red hat support contract, where someone will then fix the underlying bug (for which you now have crashdumps),
- AndrewDucker 9y ago
  I'd want it to log that it's going wrong, and report that so that it can be fixed.
- azernik 9y ago
  If you're a desktop user, or a sysadmin without said support contract, you want the former.
- marcosdumay 9y ago
  What data exactly is being corrupted? Fail fast is a great philosophy for end-user software. But it is not that strictly good for middleware, and is almost certainly wrong for a kernel.
- jandrese 9y ago
  That Redhat support contract won't save you from a bug in a binary blob network driver. Crashing the whole kernel at the drop of a hat seems like a pretty extreme stance to take as a general policy IMHO. Killing and restarting the driver will usually suffice, although some data may be lost and have to be retransmitted.
holri 9y ago
I want both. Panic in a test/development kernel, do not panic in a production environment.
- hutzlibu 9y ago
  Well, only that most devices never were tested over months in development kernel ... and it is not possible to do so, with all those million different devices around.
- snvzz 9y ago
  Absolutely panic in a production environment. Potential data corruption is far worse, so is a potential security compromise.
  - eeZah7Ux 9y ago
    It really depends on the use case! E.g. performing industrial control automation or airplane rudder control in a completely segregated network. You want control over these tradeoffs, not hardcoded behaviors.
    - snvzz 9y ago
      Linux is ill suited for that. Look at seL4, minix3, eChronos instead.
- TickleSteve 9y ago
  It the opposite... you should panic in a production environment and reset the state of the machine (which has become indeterminate). The correctness and validity of the data >> uptime.
  - pilif 9y ago
    As so often, it really depends. Let's say you've just detected that you're going to send incorrect data because you've ended up in an indeterminate state. If the remote end is going to ignore that data anyways, would it really be such a bad idea to keep running? Do you really want to go down in order to ensure that a remote who's ignoring your data can get correct data to ignore? Of course you never know what sort of effect the corrupt data is going to have, so it's always hard to make that decision. Like that issue with libraries linking against objective-c frameworks that has crept up with High Sierra and broke most of the Ruby world: Yes. The usage was incorrect. Yes, forking after threads are launched leads to undefined behavior, yes, knowing about it is a good thing. But: So far the crashes have been rare in the common use-cases (or they would have been fixed), so High Sierra's change to blow up loudly when it detects the misuse has actually caused a lot of trouble for people where things worked fine before. To the point where many Ruby developers were complaining about High Sierra "breaking" their workflow and recommending against upgrading. The new check is totally justified though. The existing forking behavior was wrong and it could have lead to crashes down the line. It didn't though. And now people are forced to fix something that was never an issue to begin with. It's a fine line to walk and while I generally prefer things to blow up as they go wrong, sometimes I catch myself wishing for stuff to just continuing to work. On some self-reflection, I come to the conclusion that I want my cake and eat it too.

jbangert 9y ago

But do you want your box to send silently corrupted data for the next two years? Or would you rather reboot every night, and maybe escalate to your red hat support contract, where someone will then fix the underlying bug (for which you now have crashdumps),

AndrewDucker 9y ago
I'd want it to log that it's going wrong, and report that so that it can be fixed.
azernik 9y ago
If you're a desktop user, or a sysadmin without said support contract, you want the former.
marcosdumay 9y ago
What data exactly is being corrupted? Fail fast is a great philosophy for end-user software. But it is not that strictly good for middleware, and is almost certainly wrong for a kernel.
jandrese 9y ago
That Redhat support contract won't save you from a bug in a binary blob network driver. Crashing the whole kernel at the drop of a hat seems like a pretty extreme stance to take as a general policy IMHO. Killing and restarting the driver will usually suffice, although some data may be lost and have to be retransmitted.

holri 9y ago

I want both. Panic in a test/development kernel, do not panic in a production environment.

hutzlibu 9y ago
Well, only that most devices never were tested over months in development kernel ... and it is not possible to do so, with all those million different devices around.
snvzz 9y ago
Absolutely panic in a production environment. Potential data corruption is far worse, so is a potential security compromise.
- eeZah7Ux 9y ago
  It really depends on the use case! E.g. performing industrial control automation or airplane rudder control in a completely segregated network. You want control over these tradeoffs, not hardcoded behaviors.
  - snvzz 9y ago
    Linux is ill suited for that. Look at seL4, minix3, eChronos instead.
TickleSteve 9y ago
It the opposite... you should panic in a production environment and reset the state of the machine (which has become indeterminate). The correctness and validity of the data >> uptime.
- pilif 9y ago
  As so often, it really depends. Let's say you've just detected that you're going to send incorrect data because you've ended up in an indeterminate state. If the remote end is going to ignore that data anyways, would it really be such a bad idea to keep running? Do you really want to go down in order to ensure that a remote who's ignoring your data can get correct data to ignore? Of course you never know what sort of effect the corrupt data is going to have, so it's always hard to make that decision. Like that issue with libraries linking against objective-c frameworks that has crept up with High Sierra and broke most of the Ruby world: Yes. The usage was incorrect. Yes, forking after threads are launched leads to undefined behavior, yes, knowing about it is a good thing. But: So far the crashes have been rare in the common use-cases (or they would have been fixed), so High Sierra's change to blow up loudly when it detects the misuse has actually caused a lot of trouble for people where things worked fine before. To the point where many Ruby developers were complaining about High Sierra "breaking" their workflow and recommending against upgrading. The new check is totally justified though. The existing forking behavior was wrong and it could have lead to crashes down the line. It didn't though. And now people are forced to fix something that was never an issue to begin with. It's a fine line to walk and while I generally prefer things to blow up as they go wrong, sometimes I catch myself wishing for stuff to just continuing to work. On some self-reflection, I come to the conclusion that I want my cake and eat it too.