Re: 2.6.18-rc3-g3b445eea BUG: warning at /usr/src/linux-git/kernel/cpu.c:51/unlock_cpu_hotplug()

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

>> >  [<c0171577>] vfs_write+0xcd/0x179
>> >  [<c0171c20>] sys_write+0x3b/0x71
>> >  [<c010318d>] sysenter_past_esp+0x56/0x8d
>> This "unwinder stuck" thing seems to be very common.
>
>Yes, there are still a lot of bugs in the unwind annotation
>unfortunately.
>
>We're also slowly discovering that some things we do cannot
>even be expressed in CFI, so some code has to change.
>
>> 
>> It's a false-positive in this case - the backtrace was complete.  It
would
>> be good if we could make the did-we-get-stuck detector a bit
smarter.  Even
>> special-casing "sysenter_past_esp" would stop a lot of this..
>
>Actually it's not completely false in this case -- it should
>have reached user mode and stopped there, but for some reason
>I didn't and already stopped still in the kernel.
>
>Most likely the CFI annotation for that sysenter path is not
complete.

They seem to be correct, at least on the default path. I have no
problem with it finding and stopping at the first user frame; I'd like
to note, however, that this (a) is *with* the patches I sent earlier
today (they didn't change anything annotation-wise) and (b) the
size reported for sysenter_past_esp is slightly different on my
system (above trace says 0x8d, mine is 0x79), while the offsets
are 0x56 in both cases. I'd assume the size delta is due to
CONFIG_TRACE_IRQFLAGS, which then I can't see how it would
make a difference other than in the case where
trace_hardirqs_{on,off} themselves would fault (as their call
sites are un-annotated), which doesn't appear to be the case
here.

Again, if "unwinder stuck" messages appear, I'll need a raw
stack dump to accompany the stack trace.

>It's on my todo list to investigate but I still hope Jan does it first
;-)

Jan