Re: [Xen-devel] [xen-unstable test] 112855: regressions - trouble: blocked/broken/fail/pass

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.08.17 at 15:57, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 08/28/2017 03:25 AM, Jan Beulich wrote:
>>>>> On 25.08.17 at 19:14, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> On 08/25/2017 09:40 AM, Jan Beulich wrote:
>>>>>>> On 25.08.17 at 05:15, <osstest-admin@xxxxxxxxxxxxxx> wrote:
>>>>> flight 112855 xen-unstable real [real]
>>>>> http://logs.test-lab.xenproject.org/osstest/logs/112855/ 
>>>>>
>>>>> Regressions :-(
>>>>>
>>>>> Tests which did not succeed and are blocking,
>>>>> including tests which could not be run:
>>>>>  test-amd64-i386-examine       7 reboot                   fail REGR. vs. 
>>>>> 112809
>>>>>  test-amd64-i386-freebsd10-amd64  7 xen-boot              fail REGR. vs. 
>>>>> 112809
>>>> These two are watchdog NMIs during the loading of Dom0. Most
>>>> likely candidate for introducing the issue is Boris' scrub series.
>>>
>>> I haven't been able to reproduce this but perhaps adding
>>> process_pending_softirqs() in alloc_heap_pages() and free_heap_pages()
>>> loops if CONFIG_SCRUB_DEBUG is set might help?
>> That's possible, but might as well only be papering over a deeper
>> issue, e.g. ...
>>
>>> One other thing that also comes to mind is that there is probably no
>>> reason to scrub (and in some cases poison) pages during dom0 creation.
>> ... this one: Iirc before your series Dom0 pages weren't being
>> scrubbed, and imo this property ought to be retained (also if
>> any other boot time allocations now suddenly got scrubbed).
> 
> It is scrubbed if CONFIG_SCRUB_DEBUG in free_domheap_pages:
> 
> #ifndef CONFIG_SCRUB_DEBUG
>             /*
>              * Normally we expect a domain to clear pages before freeing
> them,
>              * if it cares about the secrecy of their contents. However,
> after
>              * a domain has died we assume responsibility for erasure.
>              */
>             scrub = !!d->is_dying;
> #else      
>             scrub = true;
> #endif
> 
> so the question is whether we need to do this (at least for dom0).

We should start doing this only once Dom0 started running, imo.

> As for periodically testing process_pending_softirqs() we may still want
> to do this in alloc_heap_pages(), even without CONFIG_SCRUB_DEBUG.

For my taste, alloc_heap_pages() is the wrong place for such
calls.

> And
> while at it, also think we can execute the 'for' loop without holding
> heap lock since the pages are now removed from the heap (or do we need
> to modify count_info/type_info/owner under the lock?)

I don't think these fields need updating with the heap lock held.

Jan


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