: : :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 state. 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. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message