how to completely crash minix - Minix

This is a discussion on how to completely crash minix - Minix ; All, On 2007-09-13, Matej Kosik wrote: > Unfortunately, I am not able to upgrade from Minix 3.1.2a to SVN > trunk. Whenever I do that, I end up with unmountable root filesystem. > > /dev/c1d0: No such file or directory ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 23 of 23

Thread: how to completely crash minix

  1. Re: how to completely crash minix

    All,

    On 2007-09-13, Matej Kosik wrote:
    > Unfortunately, I am not able to upgrade from Minix 3.1.2a to SVN
    > trunk. Whenever I do that, I end up with unmountable root filesystem.
    >
    > /dev/c1d0: No such file or directory


    Upgrading from 3.1.2a to current is very rocky, yes.

    > If you generate new CD image (or even better, publish a QEMU image), I
    > will be able to check it.


    Bleeding edge images are here:

    > You say that the above program when loaded
    > as a driver will not cause denial of service after someone requests
    > services of such a that driver?


    It depends on how robust the server that does the request is to message
    protocol violations. Currently, VFS/MFS are not robust (hanging
    filesystem processes resp. device drivers will currently hang VFS/MFS),
    but e.g. INET should be, hence Philip's example.

    =Ben



  2. Re: how to completely crash minix

    On Sep 13, 1:38 pm, Ben Gras wrote:
    > All,
    >
    > On 2007-09-13, Matej Kosik wrote:
    >
    > > Unfortunately, I am not able to upgrade from Minix 3.1.2a to SVN
    > > trunk. Whenever I do that, I end up with unmountable root filesystem.

    >
    > > /dev/c1d0: No such file or directory

    >
    > Upgrading from 3.1.2a to current is very rocky, yes.
    >
    > > If you generate new CD image (or even better, publish a QEMU image), I
    > > will be able to check it.

    >
    > Bleeding edge images are here:
    >
    > > You say that the above program when loaded
    > > as a driver will not cause denial of service after someone requests
    > > services of such a that driver?

    >
    > It depends on how robust the server that does the request is to message
    > protocol violations. Currently, VFS/MFS are not robust (hanging
    > filesystem processes resp. device drivers will currently hang VFS/MFS),
    > but e.g. INET should be, hence Philip's example.
    >
    > =Ben


    You are right. I have checked that because I wanted to be sure about
    it. The above trivial (but buggy) device driver hangs the whole OS and
    thus it is (from very strict point of view) part of TCB. Do you think
    that this kind of problem can be solved with the present communication
    primitives?

    Note that Erlang has a construct

    receive
    pattern -> action
    pattern -> action
    after
    action
    end

    Maybe something similar could be added to Minix too but it would be
    elegant (although Erlangers like it). Playing with Erlang I realized
    how the idea of named processes is bad. To be able to do RPC it is
    necessary to emulate "selective receive" with invening "unique" tags.
    This is ugly. In Pict we have communication over channels (rather than
    communication between processes) and this gives the programmer a lot
    of freedom. A request can be received on one channel whereas client
    can specify where he wants the reply. The server might do something
    and dispatch the request further asynchronously and immediatelly
    devote itself in serving next request. Finally, someone sends proper
    answer through proper channel to the original client.

    However, by studying Minix I have realized that your organization of
    processes (almost) has some hidden value. Processes (in Minix almost
    but not completely) form partial ordering---from the point of view who
    is allowed to activate whom via RPC. Activation from the bottom are
    always asynchronous. This way deadlock is excluded (albeit
    interference still could happen if things are not programmed well). In
    Minix this is almost true. Not completely because between PM and FS
    happens some kind of weird communication that does not obey these
    rules.

    I wonder whether it is possible to organize OS that follows such
    ordering of processes without exceptions. OS is a small world so I
    believe something similar is possible.

    In my experiments, wherever possible, I use asynchronous message
    passing. Handlers of IRQs (in kernel space) or UNIX signals (in user
    space) must not be function abstractions (that should be synchronously
    called). They must be process abstractions (that, when sent an
    appropriate signal message start to run. This does not block the
    sender). This way the more trusted parts are guarded from handlers
    that "do not return".


  3. Re: how to completely crash minix

    All,

    > You are right. I have checked that because I wanted to be sure about
    > it. The above trivial (but buggy) device driver hangs the whole OS and
    > thus it is (from very strict point of view) part of TCB. Do you think
    > that this kind of problem can be solved with the present communication
    > primitives?


    Yes; for the VFS example, a fully asynchronous VFS that uses
    asynchronous send should be able to cope with any kind of filesystem
    misbehaviour. As Philip noted in an earlier reply to you, there are
    plans to actually do this. As I see it, this is no limitation of minix,
    but a server implementation issue.

    =Ben



+ Reply to Thread
Page 2 of 2 FirstFirst 1 2