Re: [patch] i386: annotate the rest of entry.s::nmi

["Jan Beulich" <jbeulich@novell.com>]

>> >> The point is that the push-es in FIX_STACK() aren't annotated, so
>> >> things won't be correct at those points anyway.
>> >
>> >I have a patch here that adds that, but it won't compile
>> >because that part of the NMI handler is un-annotated:
>> 
>> But you didn't clarify why you need this piece of code annotated...
>
>Uh, which one didn't I clarify?
>
>FIX_STACK() is already invoked from debug(), which is annotated, but
>FIX_STACK() isn't.  And that messes with the stack, so for a few
>instructions the annotations are all wrong.
>
>When I annotated FIX_STACK(), I found entry.S wouldn't compile
because
>nmi() included FIX_STACK() but was completely missing annotations
>in that piece. So I added them so FIX_STACK()'s annotations would
>compile...

Ah, okay, this means the original sequence of additions was the reverse
of
how I got to see these patches. I understand now, but am still
uncertain
about the need to annotate FIX_STACK() - especially since you use
.cfi_undefined, meaning the return point cannot be established anyway.
If at all I'd annotate the initial pushes with either just the normal
CFI_ADJUST_CFA_OFFSET, and the final one with one setting back the
CFA base to the now adjusted frame. That way, until the pushes are
complete the old frame will be used for determining the call origin,
and
once complete the (full) new state will be used.
Or annotate them so that the new values take effect immediately with
each push, but clearly without any CFI_UNDEFINED. That way, the
frame will be slightly inconsistent in between, which could be of
concern
once we also properly annotate the segment register spills/restores.

>Should I send a combined patch, leave the two patches separate, or
just
>drop it?

Either way, but if you leave them separate you should always send them
as pair, to make the intentions clear.

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/