Re: FUSYN and RT

From: Esben Nielsen (simlo_at_phys.au.dk)
Date: 04/12/05

  • Next message: akpm_at_osdl.org: "[patch 024/198] SELinux: add support for NETLINK_KOBJECT_UEVENT" 
    Date:	Tue, 12 Apr 2005 22:29:36 +0200 (METDST)
To: Daniel Walker <dwalker@mvista.com>

    On 12 Apr 2005, Daniel Walker wrote:

    >
    > I just wanted to discuss the problem a little more. From all the
    > conversations that I've had it seem that everyone is worried about
    > having PI in Fusyn, and PI in the RT mutex.
    >
    > It seems like these two locks are going to interact on a very limited
    > basis. Fusyn will be the user space mutex, and the RT mutex is only in
    > the kernel. You can't lock an RT mutex and hold it, then lock a Fusyn
    > mutex (anyone disagree?). That is assuming Fusyn stays in user space.
    >
    > The RT mutex will never lower a tasks priority lower than the priority
    > given to it by locking a Fusyn lock.

    I have not seen the Fusyn code. Where is the before-any-lock priority
    stored? Ingo's code sets the prio back to what is given by static_prio.
    So, if Fusyn sets static_prio it will work as you say. It it will then be
    up to Fusyn to restore static_prio to what it was before the first Fusyn
    lock.

    >
    > At least, both mutexes will need to use the same API to raise and lower
    > priorities.

    You basicly need 3 priorities:
    1) Actual: task->prio
    2) Base prio with no RT locks taken: task->static_prio
    3) Base prio with no Fusyn locks taken: task->??

    So no, you will not need the same API, at all :-) Fusyn manipulates
    task->static_prio and only task->prio when no RT lock is taken. When the
    first RT-lock is taken/released it manipulates task->prio only. A release
    of a Fusyn will manipulate task->static_prio as well as task->prio.

    >
    > The next question is deadlocks. Because one mutex is only in the kernel,
    > and the other is only in user space, it seems that deadlocks will only
    > occur when a process holds locks that are all the same type.

    Yes.
    All these things assumes a clear lock nesting: Fusyns are on the outer
    level, RT locks on the inner level. What happens if there is a bug in RT
    locking code will be unclear. On the other hand errors in Fusyn locking
    (user space) should not give problems in the kernel.

    >
    >
    > Daniel
    >

    I think that it might be a fast track to get things done to have a double
    PI-locking system, one for the kernel and one for userspace. But I think
    it is is bad maintainance to have to maintain two seperate systems. The
    best way ought to be to try to only have one PI system. The kernel is big
    and confusing enough as it is!

    Esben

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: akpm_at_osdl.org: "[patch 024/198] SELinux: add support for NETLINK_KOBJECT_UEVENT"

    Relevant Pages

    • Re: FUSYN and RT
      ... >> to hold a fusyn lock, then block on an RT lock. ... >> will be problems when the RT mutex tries to restore the priority. ...
      (Linux-Kernel)
    • Re: FUSYN and RT
      ... Fusyn will be the user space mutex, and the RT mutex is only in ... You can't lock an RT mutex and hold it, then lock a Fusyn ... locks a kernel semaphore. ...
      (Linux-Kernel)
    • Re: [PATCH] Priority Lists for the RT mutex
      ... > Fusyn is now a generic implementation, similar to the RT mutex. ... they come in small, clean steps. ... is priority ceiling coming in via some POSIX feature that fusyn's need ...
      (Linux-Kernel)
    • RE: FUSYN and RT
      ... > to hold a fusyn lock, then block on an RT lock. ... > will be problems when the RT mutex tries to restore the priority. ...
      (Linux-Kernel)
    • FUSYN and RT
      ... having PI in Fusyn, and PI in the RT mutex. ... You can't lock an RT mutex and hold it, ... The RT mutex will never lower a tasks priority lower than the priority ...
      (Linux-Kernel)