Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept).

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 04/09/04

  • Next message: John-Mark Gurney: "Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept)." 
    Date: Fri, 9 Apr 2004 10:38:53 -0400 (EDT)
To: Seigo Tanimura <tanimura@tanimura.dyndns.org>

    On Fri, 9 Apr 2004, Seigo Tanimura wrote:

    > (3) Let a dedicated kernel thread call the methods of struct
    > filterops.
    >
    > The headache of kqueue is that KNOTE() ultimately calls back the caller
    > subsystem. Tty would suffer from the same pain as well.
    >
    > Assuming that a kqueue event need not be delivered synchronously upon
    > the event, maybe we can attach an event queue to a knote list. KNOTE()
    > appends an event to the queue and wakes up a dedicated kernel thread
    > (kqueued). It then dequeues the event in a queue to call a filter
    > *without* the lock of the event source. (socket, tty, etc.)

    Such an approach would be fine by me, but it would also have some
    complications. For example, we need to make sure we handle the case where
    a kqueue event thread wakes up to handle a socket event, but the socket
    has been free'd. It's not all that bad, it just involves a necessary
    amount of paperwork as well. It does seem that the fundamental problem
    here is that KQueue is one of the more incestuous of support subsystems in
    the kernel, and a little bit of redesign might well be called for, because
    it will simplify the locking, but probably also clean up other concerns.
    The MAC Framework is also an incestuous subsystem, but it does a lot less
    "calling back" than KQueue does.

    Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
    robert@fledge.watson.org Senior Research Scientist, McAfee Research

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: John-Mark Gurney: "Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept)."

    Relevant Pages

    • Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept).
      ... >> The headache of kqueue is that KNOTEultimately calls back the caller ... maybe we can attach an event queue to a knote list. ... > The MAC Framework is also an incestuous subsystem, but it does a lot less ... If you treat the KNOTE lock as a leaf lock, ...
      (freebsd-arch)
    • kqueue giant-locking (&kq_Giant, locking)
      ... with no ill effect:) The locking thus far is one global kqueue lock, ... KNOTE() can't end up calling another KNOTEunless ... Kqueue does the locking for you when it comes to the non-object lists. ... KNOTEwith locks held, but you should reference your object. ...
      (freebsd-arch)
    • Re: Kqueue write event position?
      ... On 11/23/06, Ivan Voras wrote: ... > It seems to me you would have to propagate that info along the ... > knote() is generic and is used for all types of notifications, ... For kqueue to work, each file would have to be opened (and take ...
      (freebsd-hackers)
    • Re: lio_listio fixes and adding kqueue notification patch
      ... > Here's a patch to fix some lio_listio bugs and add kqueue support to it. ... > during the locking changes. ... there could be a knote added... ... [aio stuff deleted] ...
      (freebsd-current)
    • once again, MP-safe kqueue...
      ... EVFILT_PROC+NOTE_TRACK and allows recursing KNOTE() ) calls. ... There is one subsystem lock still, ... There can be one writer which may sleep and drop the kqueue subsystem ...
      (freebsd-arch)