Hacker News Reader

Comment by AnIdiotOnTheNet | Hacker News Reader

I agree with a comment from the SO thread: "And thus a simple, solvable hardware or locking problem will escalate to a major problem, needing reboot. And the kernel people doesn't even understand, that it is a… a… suboptimal handling of the things"

This is an example of the kind of thing that really irks me about developers, where they insist that they know better than the user and artificially constrain them "for their own good". It's one thing to make something difficult to do accidentally, it's another to prevent it entirely. I've run into unkillable task problems many times, and every time it happens on Linux I think back to the 90s when annoying linux evangelists would joke about how Windows required a reboot to fix things.

View on HN

I disagree. The defect is not that you can't kill these tasks, the defect is that the I/O wasn't terminated by a timeout somewhere in the kernel/driver.

> where they insist that they know better than the user and artificially constrain them "for their own good".

I'm not sure where this comes from but if it's the intended design of linux (to not be able to kill tasks in the uninterruptible state), then that's their design. You're free to design your own operating system without this limitation -- though it likely means just taking the other side of the tradeoffs involved here.

It's not as if linux designers think "tasks holding resources that can't be killed by a sysadmin are a good thing" rather instead "letting tasks currently executing kernel code to be interrupted is a bad thing." And you could imagine other solutions that might liberate you from the dilemma entirely, but then that wouldn't be linux anymore.

> I disagree. The defect is not that you can't kill these tasks, the defect is that the I/O wasn't terminated by a timeout somewhere in the kernel/driver.

Defects happen. This is sorta like saying you don't need ASLR because the real defect is that some code allows buffer overflows. Things don't always work perfectly and when they don't you still need tools to deal with it.

> You're free to design your own operating system without this limitation

Such an OSS response to criticism. This attitude is awful and a big part of the reason software sucks.

> It's not as if linux designers think "tasks holding resources that can't be killed by a sysadmin are a good thing" rather instead "letting tasks currently executing kernel code to be interrupted is a bad thing."

The problem is that they fail to recognize that there are potentially cases where even though it is a bad thing, it is still the least-bad option. It comes down to a fundamental philosophical disagreement, I guess. I think the computer belongs to the user and they should be able to do things even if they are dangerous as long as they acknowledge and accept that danger. But there is this -- unfortunately very prolific -- idea among developers out there that the computer belongs to them and users are beneath them, a lower life form incapable of making their own decisions that needs to have their hands tied.

> The problem is that they fail to recognize that there are potentially cases where even though it is a bad thing, it is still the least-bad option

You are way oversimplifying the problem. Linux designers want a nice, stable OS with good performance. Introducing a new mode where signals can asynchronously interrupt a task means that you have to account for your kernel code to not only be safe when CPU interrupts occur, but now when user space signal handlers execute too. To be safe means that you'd need to sprinkle fences/barriers over lots of code. This flushes pipelines and unnecessarily forfeits performance. Performance aside, it's really hard to imagine the problems caused by asynchronous interrupts until they actually occur. As a designer, it's much simpler to just bar them for the critical region. Now, it's totally reasonable for us to discuss 'hey can we minimize these critical regions somehow, to make these problems less likely?'

If you did a `kill -9 1234` and then your computer suddenly hit an NMI, whose bug would that be? The kernel's! You'd say "hey, kernel, wtf, I was just trying to reap this process and then my computer rebooted." And you'd be right.

There's lots of design decisions made early on in linux that are likely baked in and hard to change without impacting user space.

For you to declare it "the least-bad option" you have to be able to evaluate it from the designer's perspective. From the user's perspective, I agree that it's clearly not ideal. But there's much more at stake here.

> idea among developers out there that the computer belongs to them and users are beneath them

You're introducing some motives that just aren't there. Linux is all about enabling people. Perhaps we can agree that the death of general purpose computing is nigh [1], but it's not linux's fault.

>> You're free to design your own operating system without this limitation

> Such an OSS response to criticism. This attitude is awful

I don't agree. But I will express regret that I didn't say instead "you're free to use another OS without this limitation" -- that's a more realistic option for a user.

For a user to casually say "you made the wrong design decision here" without acknowledging the existence of the tradeoff is unfair.

[1] https://boingboing.net/2012/08/23/civilwar.html

Why does such a feature have to be safe? It's for an edge case where something is misbehaving badly, and your only alternative is a reboot. Why shouldn't the user be able to do this as long as they accept the risk?

> Linux is all about enabling people

Since we're talking about the kernel, I agree for the most part. Which makes it all the more annoying that "reboot" (and sometimes even that doesn't work and you have to smother the system with a pillow) is the only option in this circumstance. I can overwrite disks and memory at will, destroying who knows what data, but I can't kill a useless hung process because it might be unsafe?

Admittedly I am ignorant of the details of the kernel implementation, but I have difficulty believing that there is nothing that can be done.

Say your kernel panics 10 minutes later, due to an unplanned state caused by ripping the process out of the table.

What then?

Stuck mount, or unplanned, immediate restart?

See the dilemma?

This way, you can keep working, save what may be super important, and then restart.

In reply to "AnIdiotOnTheNet"'s: >> idea among developers out there that the computer belongs to them and users are beneath them

"wyldfire" wrote: > You're introducing some motives that just aren't there. Linux is all about enabling people.

Yeah, that would be nice. But perhaps one would be more inclined to believe it were true, if you hadn't in your paragraph above that written:

> For you to declare it "the least-bad option" you have to be able to evaluate it from the designer's perspective.

Huh? No, isn't it the designer(s) of the operating system who should evaluate things from the perspective of the actual owner of the computer???

Especially if what they're doing is "all about enabling people"?

> The problem is that they fail to recognize that there are potentially cases where even though it is a bad thing, it is still the least-bad option. It comes down to a fundamental philosophical disagreement, I guess. I think the computer belongs to the user and they should be able to do things even if they are dangerous as long as they acknowledge and accept that danger. But there is this -- unfortunately very prolific -- idea among developers out there that the computer belongs to them and users are beneath them, a lower life form incapable of making their own decisions that needs to have their hands tied.

I don't think you really recognize the complexity here. Even if you could conceivably 'kill' the task, the kernel would still be in a broken state. It wouldn't fix the problem, it would just create a bigger one - now you have absolutely no hope of recovering as the task that could do so is gone. Keep in mind a task in `TASK_UNINTERRUPTIBLE` is already sleeping, it's not doing anything. Killing it doesn't change anything or unblock the kernel, it just removes the `task` from the scheduler.

On that note though, it's worth noting the kernel people do (or rather, did) recognize this is a problem, hence why is has already been addressed in several different ways. As mentioned above, timeouts solve the problem in most cases (And if there isn't a timeout, that's probably a bug), but the `TASK_KILLABLE` state was added around 10 years or so ago to solve this problem - as a properly written kernel task that sleeps in that state can be killed like normal and will leave the kernel in a safe state when killed.

> Keep in mind a task in `TASK_UNINTERRUPTIBLE` is already sleeping, it's not doing anything. Killing it doesn't change anything or unblock the kernel, it just removes the `task` from the scheduler.

....so why can't I force that? When you encounter this problem recovery isn't ever going to happen anyway.

It's already in a state where it can't get back on the run list. The problem isn't that it's going to eat your CPU cycles, the problem is that it's still holding resources that you want it to give back. Taking it out of the process list won't give back those resources, it would just make it so it doesn't show up under `ps`.

> When you encounter this problem recovery isn't ever going to happen anyway.

The kernel's design can't distinguish between this unrecoverable situation and the normal functionality. Or rather it could, if it had a sane timeout. It doesn't, that's the defect.

And there's really no way around that? I find this difficult to believe, but whatever. Guess I just have to live with stuck mounts and other crap.

>users are beneath them

More like they do not want to support all cases. So they don't.

Allowing a least bad type option that gets abused, or not well understood, may well result in a different, negative, "why allow this?" dialog.

Liabilities, obligations all can expand on something like this. Not always an easy call.

Well, in the 90s Windos usually required a reboot after modify a config setting, like the host IP address...

i’m told it still does if it’s a domain controller

Couldn't it be argued that a design without these unintereuptable states artificially constrains the user (of the driver) by preventing them from entering a state where all signals are blocked?

Not saying these should be the primary considerations, but I don't really understand how "don't artificially constrain the user" can be a consistent design principle...

Reply on news.ycombinator.com