[Gllug] Unkillable process

[t.clarke]

-------------------------------------------
Message from:-
Tim Clarke  (tim at seacon.co.uk)
Seacon Group Ltd / Seacon Terminals Ltd,
Tower Wharf, Northfleet, Kent, DA11 9BD, UK
Telephone: +44 (0)1474 320000
      Fax: +44 (0)1474 329946
-------------------------------------------

Nix wrote:-

>
>On Wed, 26 Jun 2002, t. clarke muttered drunkenly:
>> This has long struck me as a failing of Unix/linux kernels - the inability
>> to kill processes in certain states.  Maybe someone involved in kernel
>> development should look at ways of killing processes from within the kernel
>> by means of a system-call, rather than sending the process a signal ?
>
>The problem is, what happens if that process has kernel locks held?
>Normally things are in uninterruptible sleep for precisely that reason,
>and they've normally got locks held because they're doing things to
>kernel data structures that other processes would be deeply confused by
>(i.e., because they're enforcing atomiticity).
>
>So to safely kill a D-state process you'd need to snap its locks and
>roll back all the changes to data structures it had made: that is, you'd
>need a transaction management layer deep inside the kernel which all the
>device drivers use.
>
>Think of the performance hit. :(


I was perfectly sober at the time ! - but maybe showing my ignorance.

Why would any sane operating system want to allow user processes to modify
kernel structures? I though the general idea of robust multi-user OS's was
to protect the kernel from users and users from each other !!  I have obviously
missed something, 'cos I though that generally speaking programs just executed
code and did system calls, leaving the kernel code to do whatever was requested.

Does an 'uninterruptable sleep' imply that a process has asked the kernel to
do something which for some reason it (the kernel) can't complete ??


Tim



-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug