:On 24-Feb-02 Matthew Dillon wrote:
:>     Apart from all the assembly coding, there were two serious issues.
:>     fork_exit() assumes that interrupts are hard-disabled on entry.  I
:>     readjusted the code such that the trampoline assembly initialized
:>     the td_critnest count so it could STI prior to calling fork_exit().
:Err, this is a feature.  It isn't safe for us to take an interrupt until we
:have safeuly cleaned up and released sched_lock.

    This and your other comments only apply to systems that have a hard
    interrupt disablement side effect to critical_enter().  My critical_*()
    patch set (partially based on BDE's work) removes this requirement and
    exposes two flaws in the existing MI code (discussed on the lists
    already).  One is a flaw in fork_exit() due to it making improper 
    assumptions as to the nature of the trampoline code to close a 
    td_critnest/sched_lock initialization race, and the other is a flaw
    in ast() which uses cpu_critical_*() routines as a hack to tightly
    couple it with MD doreti().  In fact, the assembly that calls ast()
    should be responsible for placing the machine in the proper critical 

    These are not 'bugs' per say, because the flaws remain consistent
    within their domain.  But they are flaws.

    I am rather disturbed that you keep explaining the flaws and MD/MI
    cross pollution away as being a 'feature'.  It most certainly is not
    a feature.  I am also disturbed that these special interactions &
    assumptions were not documented *anywhere* in the critical_*() or
    cpu_critical_*() code.  And, finally, I am extremely disturbed about
    the logic you use to justify both the two-level critical_*() API
    and to justify the hacks in fork_exit() and ast().

    In anycase, it's going to become moot very soon now as I clean it up.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to