Not entirely random thought

Mainly directed at folks such as robbat2 and zaitcev:

What would it take to add the ability into a *nix kernel to kill a process that's in uninterruptible sleep due to, say, a hardware fault?  Say I have an external device, and it hangs up, and I can reset the device, but the daemon that was controlling it is still in uninterruptible sleep.  I really should be able to tell the kernel, "Look, I don't care that the process isn't responding, I SAID KILL IT, RIGHT NOW", and have the kernel do it.  Never mind trying to play nice with the process, just forcibly terminate its execution and free all of its allocated memory, ports, sockets etc.  Sort of a kill -9 on steroids.  SIG_TERM, SIG_KILL, SIG_EXTREME_PREJUDICE.  If the process is non-responsive and in uninterruptible sleep, that's most likely the reason WHY I want it terminated, without having to rely on the target process doing anything in response to a signal.  (OK, for that reason it wouldn't really actually be a signal, it'd be more of a kernel-instigated purge-process facility.  And per the point raised by ithildae, it should probably require UID0 to call it.)

Would there be any downsides to doing so?  Reasons why the capability would be a bad idea?

Being able to do that could save a reboot, or at least let you postpone a reboot until you're done with whatever it was you were working on.  It's always seemed odd to me that even a SIGKILL requires at least minimal cooperation on the part of the process being killed.

Ïa! Ïa! Ïackabooooooo!

Also known as, The Great Elder Old One of Bexhill-on-Sea (Part One).

No, seriously, imagine the potential for sheer undiluted insanity inherent in an all-posthumous Goon Show - H. P. Lovecraft crossover...