Date: Mon, 25 Feb 2002 23:35:07 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: current@FreeBSD.org, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, Bosko Milekic <bmilekic@unixdaemons.com>, Alfred Perlstein <alfred@FreeBSD.org>, Terry Lambert <tlambert2@mindspring.com>, Bruce Evans <bde@zeta.org.au> Subject: Re: RE: Success! critical_enter()/critical_exit() revamp (was Re: m Message-ID: <200202260735.g1Q7Z7i57111@apollo.backplane.com> References: <XFMail.020226020937.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:
: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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202260735.g1Q7Z7i57111>