Solution for Pseudo Stacks of Tasks - Minix

This is a discussion on Solution for Pseudo Stacks of Tasks - Minix ; Hi all, once again - I'm currently about to port MINIX 3 to a research processor platform. i found some inconvenience as I was thinking about the tasks (SYSTEM TASK and CLOCK TASK) and the code that runs in consequence ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Solution for Pseudo Stacks of Tasks

  1. Solution for Pseudo Stacks of Tasks

    Hi all,

    once again - I'm currently about to port MINIX 3 to a research
    processor platform.

    i found some inconvenience as I was thinking about the tasks (SYSTEM
    TASK and CLOCK TASK) and the code that runs in consequence of
    interrupts (let me call it the KERNEL). They each have their own
    pseudo stack in MINIX 3. I call it pseudo due to the fact, that those
    stacks are located in the same segment. Each of them is given a
    certain amount of stackspace in this segment. However, assuming the
    bad case, where one them uses more stackspace than it's been granted,
    it will destroy some of it's neigbour's stack data.

    Thus MINIX 3 doesn't try to avoid this bad case but only detects it
    using the so called STACK_GUARD word.

    IHMO there's a very easy way to completely get rid of this problem. As
    SYSTEM TASK and CLOCK TASK in MINIX 3 are declared as NON PREEMPTIBLE
    and even KERNEL is NON PREEMPTIBLE as it deactivates interrupts this
    means that they are never running in a recursive manner. Furthermore
    none of them seems to leave data on it's stack (despite static data)
    between two calls. Under this circumstances it should be possible that
    all of them share ONE segment with exactly ONE stack and ONE stack
    pointer. This stack would contain mixed data, but as none of them
    leaves data between two calls, they would find a constantly valid
    stack without the problem of stack corruption due to a nonprevented
    stack overflow.

    Did I ignore facts?

    Thanks for your comments,

    Alex

  2. Re: Solution for Pseudo Stacks of Tasks

    A. Schabel wrote:
    > Hi all,


    > once again - I'm currently about to port MINIX 3 to a research
    > processor platform.


    > i found some inconvenience as I was thinking about the tasks (SYSTEM
    > TASK and CLOCK TASK) and the code that runs in consequence of
    > interrupts (let me call it the KERNEL). They each have their own
    > pseudo stack in MINIX 3. I call it pseudo due to the fact, that those
    > stacks are located in the same segment. Each of them is given a
    > certain amount of stackspace in this segment. However, assuming the
    > bad case, where one them uses more stackspace than it's been granted,
    > it will destroy some of it's neigbour's stack data.


    > Thus MINIX 3 doesn't try to avoid this bad case but only detects it
    > using the so called STACK_GUARD word.


    > IHMO there's a very easy way to completely get rid of this problem. As
    > SYSTEM TASK and CLOCK TASK in MINIX 3 are declared as NON PREEMPTIBLE
    > and even KERNEL is NON PREEMPTIBLE as it deactivates interrupts this
    > means that they are never running in a recursive manner. Furthermore
    > none of them seems to leave data on it's stack (despite static data)
    > between two calls. Under this circumstances it should be possible that
    > all of them share ONE segment with exactly ONE stack and ONE stack
    > pointer. This stack would contain mixed data, but as none of them
    > leaves data between two calls, they would find a constantly valid
    > stack without the problem of stack corruption due to a nonprevented
    > stack overflow.


    > Did I ignore facts?


    I wouldn't know if your assumption is correct, but if it is your solution
    should work. However, something in the back of my head is whispering that
    there was some problem with the interrupt handler being interrupt right
    before being able to disable interrupts, thus creating a recursive
    interrupt handler call. However, I'm not sure if this was an unsolved
    problem or a problem that had a solution applied to it (I took the OS
    course 4 years ago, when it was still MINIX 2...). Would be worth
    investigating though.

    Regards,

    Jens


    --
    Jens de Smit
    Student Computer Science | Vrije Universiteit Amsterdam
    jfdsmit@few.vu.nl | http://www.few.vu.nl/~jfdsmit
    "[In the end, people] get furious at IT that the goddamn magic isn't working"
    -- Stewart Dean

  3. Re: Solution for Pseudo Stacks of Tasks

    On 11 Aug., 15:40, "J.F. de Smit" wrote:
    >
    > I wouldn't know if your assumption is correct, but if it is your solution
    > should work. However, something in the back of my head is whispering that
    > there was some problem with the interrupt handler being interrupt right
    > before being able to disable interrupts, thus creating a recursive
    > interrupt handler call. However, I'm not sure if this was an unsolved


    So do you think this is/was a problem directly related to the i386
    architecture?

    Alex

  4. Re: Solution for Pseudo Stacks of Tasks

    On 11 Aug., 15:40, "J.F. de Smit" wrote:
    >
    > I wouldn't know if your assumption is correct, but if it is your solution
    > should work. However, something in the back of my head is whispering that
    > there was some problem with the interrupt handler being interrupt right
    > before being able to disable interrupts, thus creating a recursive
    > interrupt handler call. However, I'm not sure if this was an unsolved


    So do you think this is/was a problem directly related to the i386
    architecture?

    Alex

  5. Re: Solution for Pseudo Stacks of Tasks

    On 11 Aug., 15:40, "J.F. de Smit" wrote:
    >
    > I wouldn't know if your assumption is correct, but if it is your solution
    > should work. However, something in the back of my head is whispering that
    > there was some problem with the interrupt handler being interrupt right
    > before being able to disable interrupts, thus creating a recursive
    > interrupt handler call. However, I'm not sure if this was an unsolved


    So do you think this is/was a problem directly related to the i386
    architecture?

    Alex

  6. Re: Solution for Pseudo Stacks of Tasks

    A. Schabel wrote:
    > On 11 Aug., 15:40, "J.F. de Smit" wrote:
    >>
    >> I wouldn't know if your assumption is correct, but if it is your solution
    >> should work. However, something in the back of my head is whispering that
    >> there was some problem with the interrupt handler being interrupt right
    >> before being able to disable interrupts, thus creating a recursive
    >> interrupt handler call. However, I'm not sure if this was an unsolved


    > So do you think this is/was a problem directly related to the i386
    > architecture?


    I'd have to look that up, but I'm very short on time right now. I'll give
    you an answer if my schedule lets up a little soon.

    Regards,

    Jens

    --
    Jens de Smit
    Student Computer Science | Vrije Universiteit Amsterdam
    jfdsmit@few.vu.nl | http://www.few.vu.nl/~jfdsmit
    "[In the end, people] get furious at IT that the goddamn magic isn't working"
    -- Stewart Dean

  7. Re: Solution for Pseudo Stacks of Tasks

    Just to bring that topic up again....


    Someone of you got further suggestions?

    By next week my port should be ready to try using only one stack for
    the TASKS and KERNEL.

    Regards,

    Alex

+ Reply to Thread