Re: [Xen-devel] [xen-unstable test] 113562: regressions - FAIL

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 09/18/2017 11:26 AM, Wei Liu wrote:
> On Mon, Sep 18, 2017 at 11:15:03AM +0100, George Dunlap wrote:
>> On 09/18/2017 10:45 AM, Roger Pau Monné wrote:
>>> On Mon, Sep 18, 2017 at 10:37:58AM +0100, Wei Liu wrote:
>>>> On Mon, Sep 18, 2017 at 08:36:03AM +0000, osstest service owner wrote:
>>>>> flight 113562 xen-unstable real [real]
>>>>> http://logs.test-lab.xenproject.org/osstest/logs/113562/
>>>>>
>>>>> Regressions :-(
>>>>>
>>>>> Tests which did not succeed and are blocking,
>>>>> including tests which could not be run:
>>>>>  test-amd64-amd64-xl-credit2  15 guest-saverestore        fail REGR. vs. 
>>>>> 113387
>>>>
>>>> There appears to be a bug:
>>>>
>>>> http://logs.test-lab.xenproject.org/osstest/logs/113562/test-amd64-amd64-xl-credit2/serial-godello0.log
>>>>
>>>> Sep 18 01:14:28.803062 (XEN) Xen BUG at spinlock.c:47
>>>
>>> Seem to be caused because budget_lock is sometimes locked with irqsave
>>> while others not.
>>
>> Just wondering where you're getting the budget lock from?  The call
>> stack in that link makes it look like it's the RCU clean-up triggering a
>> domain destroy.  (Haven't looked deeper into the specific line numbers.)
>>
> 
> Looking at the backtrace I am not sure yet if budget_lock is the
> culprit.
> 
> But, Xen does have a requirement to distinguish IRQ-safe lock and
> IRQ-unsafe lock. The budget_lock violates that rule.

It looks that way at first glance, but actually it doesn't. :-)

All of the calls where the budget lock is grabbed without "_irqsave",
there is an ASSERT() previously that the per-scheduler private lock has
already been grabbed -- which, if true, means that irqs are already
disabled.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel