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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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).

As for periodically testing process_pending_softirqs() we may still want
to do this in alloc_heap_pages(), even without CONFIG_SCRUB_DEBUG. 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?)

-boris

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