[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] mm: Don't scrub pages while holding heap lock in alloc_heap_pages()
>>> On 05.09.17 at 16:42, <boris.ostrovsky@xxxxxxxxxx> wrote: >>> @@ -974,13 +972,39 @@ static struct page_info *alloc_heap_pages( >>> * guest can control its own visibility of/through the cache. >>> */ >>> flush_page_to_ram(page_to_mfn(&pg[i]), !(memflags & > MEMF_no_icache_flush)); >>> - >>> - if ( !(memflags & MEMF_no_scrub) ) >>> - check_one_page(&pg[i]); >>> } >>> >>> spin_unlock(&heap_lock); >>> >>> + if ( first_dirty != INVALID_DIRTY_IDX || >>> + (scrub_debug && !(memflags & MEMF_no_scrub)) ) >> Why does scrub_debug matter here?. >> >>> + { >>> + for ( i = 0; i < (1U << order); i++ ) >>> + { >>> + if ( test_bit(_PGC_need_scrub, &pg[i].count_info) ) >>> + { >>> + if ( !(memflags & MEMF_no_scrub) ) >>> + scrub_one_page(&pg[i]); >>> + >>> + dirty_cnt++; >>> + >>> + spin_lock(&heap_lock); >>> + pg[i].count_info &= ~PGC_need_scrub; >>> + spin_unlock(&heap_lock); >>> + } >>> + >>> + if ( !(memflags & MEMF_no_scrub) ) >>> + check_one_page(&pg[i]); >> Wouldn't this better be "else if", as checking a page just scrubbed >> doesn't look very useful? > > For both of these questions --- we don't want to miss a poisoned page. > For example, if a page was poisoned but for some reason is not marked > PGC_need_scrub. While I can accept this as an answer to the first question, I don't see how it relates to the second one: When MEMF_no_scrub is clear, the code above obviously scrubs the page in the first if() body - what's the point of passing it to check_one_page() right afterwards? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |