Apparently, On Fri, Mar 08, 2002 at 01:23:01AM -0800,
Matthew Dillon said words to the effect of;
>
> :I agree that the use of cpu_critical_enter/exit could use cleaning up.
> :Can you give an example of where critical_enter is used improperly?
> :You mean in fork_exit? Your changes to cpu_switch solve that problem
> :with critical_exit almost unchanged. The savecrit stuff should really
> :just be made MD. If cpu_critical_exit was changed to take the thread
> :as its argument as I suggested before this would be easy.
>
> fork_exit() is a good example. The existing code explicitly
> initializes td->td_critnest to 1 and then sets td->td_savecrit
> to CRITICAL_FORK:
>
> td->td_critnest = 1;
> td->td_savecrit = CRITICAL_FORK;
>
> It then proceeds to unlock the sched_lock spin lock.
>
> This code only works because interrupts are hard-disabled in the
> fork trampoline code. In otherwords, the code assumes that
> cpu_critical_enter() and cpu_critical_exit() play with hard interrupt
> disablement. If interrupts were enabled there would be two severe
> race conditions in the code: The first upon entering fork_exit
> prior to ke_oncpu being set, and the second when td->td_critnest is set
> to 1 prior to td_savecrit being set to CRITICAL_FORK.
>
>
> The current ast() code is another example. This code calls
> cpu_critical_enter() and cpu_critical_exit() without bothering to bump
> the critical nesting count (i.e. bypasses critical_enter() and
> critical_exit()).
>
>
> Peter's hack to fix IPI deadlocks (no longer in -current) is a
> third example. He enters a critical section using critical_enter()
> and then calls cpu_critical_exit() while still holding td_critnest = 1,
> which breaks even a conservative reading of the API :-)
>
> --
>
> There are also a huge number of places where cpu_critical_*() is
> used specifically in the I386 code for interrupt disablement. I am
> happy to clean it up, but not until after the multiple stages of
> my current patch set are in the tree because there are just too many
> places that have to be modified for me to feel comfortable doing both
> at once. Nor do I believe it makes sense to clean up cpu_critical_*()
> just to try to keep critical_*() in MI code (see below two sections).
>
>
> :Specifically I think that all of the current uses of cpu_critical_enter
> :exit outside of critical_enter exit are bugs. The use in ktr is bogus because
>
> Certainly in MI code, I agree. These cases can be attacked incrementally.
> fork_exit() will be fixed completely by my patches since it has to be
> for my code to work properly. I was planning on leaving ast() alone
> for the moment (because I am not planning on making cpu_critical_enter()
> a NOP any time soon). I would be willing to work on this after my
> patch is staged in (carrot and stick).
Ok.
>
> :there in the first place. I think that witness is an example of where
> :we need a different specifically defined to be hard interrupt disable api.
> :This is why I suggested the intr_disable/intr_restore api, which should only
> :be used in MD code and in dire circumstances otherwise, of which this case
> :qualifies. The code in ast is just structured wrong. I think that before
> :the loop was in assembler outside of the routine itself, so that it didn't
>
> Witness is a special case allright. I don't know if I agree with
> extending a hard interrupt disablement API out to MI code though.
I agree that it should be avoided. John would know better why exactly this
is needed and he may have already fixed it.
>
> :make so many assumptions about interrupt disablement. doreti which calls
> :it should look like this:
> :
> :loop:
> : cli;
> : if (there is an ast we can handle)
> : goto ast;
> : iret;
> :ast:
> : sti;
> : call ast;
> : goto loop;
> :
> :In which case ast doesn't need to loop or use critical sections at all.
> :All of the MD code I could find I think should use a different api for
> :hard interrupt disablement. They are all very MD and need this specifically,
> :which cpu_critical_enter need not necessarily do.
>
> I would agree with this methodology.
>
> :With these changes I don't see why the critical_enter/exit functions can't
> :or shouldn't remain MI.
>
> Cleaning up cpu_critical_enter()/exit would require a huge number of
> changes that I am not prepared to do right now, not only in i386, but
> in all architectures using cpu_critical_enter() and cpu_critical_exit()
> - alpha, i386 (many places), and ia64, not to mention ast(), fork_exit(),
> witness, subr_trap.c, and ktr.c. I suppose the routines could simply
> be renamed in the MD sections but the MI sections are going to be
> harder to fix.
>
> It doesn't make much sense to me to spend so much effort to leave
> two essentially one-line procedures, critical_enter() and critical_exit(),
> (++td->td_critnest + MD call, --td->td_critnest + MD call) MI when all
> the rest of the work they have to do is MD.
>
> Why are you so rabid about keeping critical_enter() and critical_exit()
> in MI sections? From my point of view leaving them MI simply makes the
> code more obfuscated, less understandable, less flexible, and, yes,
> the 'O' word...harder to optimize. I see absolutely no reason to do it
> that way.
The reason is that if they are in MI code they automatically apply to all
platforms and can't get out sync. When they are modified to handle preemption
the freebsd kernel will be fully preemptive. Not, it works on i386 and its
believed to work on alpha and powerpc is not preemptive at all and we don't
even know about ia64 (not to dump on other platforms, this is just example of
how things go sometimes). I understand that this argument may be sentimental
and may not hold water in a technial discussion. As such I will not stop you
from making them MD if you disagree (not to imply that I have the power to do
so, I don't), I just think that keeping them MI is the right thing to do.
I must admit that having them be MD will allow me to make optimizations for
sparc64 that I have wanted to. However, I do not think that this is better
for freebsd as a whole.
>
> :...
more ...
>
> :> Actually all I did there was square up icu_vector.s so it looked
> :> almost the same as apic_vector.s. I would consider that an improvement.
> :> Besides, I find it very difficult to work on those macros without
> :> tabbing out the backslashes. I moved some of the #defines around due
> :> to it otherwise being a forward reference. This turned out not to be
> :> an issue since the macros aren't actually used until later in the code,
> :> but I don't like forward referenced macros anyway so I left it in.
> :
> :These are the kinds of changes that should be done separately.
> :
> :I disagree that the tabbing changes are an improvement. They make it
> :difficult to see what actually changed, and I don't think that you
> :changed every line. I happen to find the slashes up against the instructions
> :convenient because you don't have to adjust the tabs when a change to the
> :instructions is made. I use this style in sparc64 assembler.
> :
> :The reordering is really bad, it looks like even less actually changed.
> :
> :Please make both of these changes separately.
>
> I would prefer not to touch these source files at this time. They
> work, they are readable, and frankly it is a whole lot easier to
> understand the patch by reading the post-patched assembly rather then
> the patch itself, for both apic_vector.s and icu_vector.s.
>
> If it takes two side-by-side commits separating out the code changes
> from the tabbing in order for your to agree to allow the code to be
> committed, however, I'll do it. Otherwise I think it's a waste of time.
Thanks, please do.
> The assembly is not and has never been stable so an incremental patch
> is not really that necessary for continuity.
>
> :> Insofar as diffs go, I'm afraid even the most conservative changes
> :> to the assembly to support interrupt deferral would make for a pretty
> :> big diff set.
> :>
> :> I'm not going to change them now, no, but I don't see this as being
> :> a show stopper in the least.
> :
> :Do stack traces in ddb work as expected from inside unpended interrupt
> :handlers? Please correct me if I'm wrong but I don't think they will.
> :It should look like a normal interrupt with the eip in call_fast_unpend.
> :
> :Do they also work as expected in kgdb?
> :
> :Jake
>
> I haven't tested it but they should work just fine since the fast unpend
> assembly routines are inside the bintr/eintr MCOUNT_LABEL's. So they
> should be treated the same as a normal interrupt. If ddb> can handle
> a normal interrupt it should be able to handle a fast-unpend.
>
> If it doesn't work then it's almost certainly a simple fix to adjust
> the fake trap frame which can be done post-commit.
The point is not wether its easy or not, the point is that this is an
important feature that may have been forgotten about. I use this on
a daily basis in sparc64 development and I would be upset if it was
broken there for any amount of time, not that this patch will affect it.
I am confident that you will fix any problems that arise, but I would
rather the next person that tries to do some debugging not be confused
by something being different, or by it not working and having to wait for
a fix, even if that amount of time is insignificant. If you do not feel
that this needs to be looked at before you commit then that is fine, again
I cannot stop you. I know many other committers who would not feel that
way about a patch of their own and I think that standard is worth adhereing
to. I apologize if this sounds like a lecture or if this offends you, it
is just how I feel.
Jake
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
