Re: [PATCH v1 2/6] mm/page_isolation: don't dump_page(NULL) in set_migratetype_isolate()
> Am 29.07.2020 um 20:36 schrieb Mike Kravetz : > > On 7/29/20 11:08 AM, David Hildenbrand wrote: >> I have no clue what you mean with "reintroducing this abandoning of >> pageblocks". All this patch is changing is not doing the dump_page() - >> or am I missing something important? > > My apologies!!! > No worries, thanks for reviewing!! > I got confused when I saw 'Return -EBUSY' removed from the comment and > assumed the code would not return an error code. The code now more > explicitly does return -EBUSY. My concern was when I incorrectly thought > you were removing the error return code. Sorry for the noise. > > Acked-by: Mike Kravetz > -- > Mike Kravetz > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v1 2/6] mm/page_isolation: don't dump_page(NULL) in set_migratetype_isolate()
On 29.07.20 19:31, Mike Kravetz wrote: > On 6/30/20 7:26 AM, David Hildenbrand wrote: >> Right now, if we have two isolations racing, we might trigger the >> WARN_ON_ONCE() and to dump_page(NULL), dereferencing NULL. Let's just >> return directly. > > Just curious, what call path has the WARN_ON_ONCE()/dump_page(NULL)? See below, two set_migratetype_isolate() caller racing. > >> >> In the future, we might want to report -EAGAIN to the caller instead, as >> this could indicate a temporary isolation failure only. >> >> Cc: Andrew Morton >> Cc: Michal Hocko >> Cc: Michael S. Tsirkin >> Signed-off-by: David Hildenbrand > > Hi David, > > That 'return -EAGAIN' was added as a sort of synchronization mechanism. > See commit message for 2c7452a075d4d. Before adding the 'return -EAGAIN', > I could create races which would abandon isolated pageblocks. Repeating > those races over and over would result in a good chunk of system memory > being isolated and unusable. It's actually -EBUSY, it should maybe later be changed to -EAGAIN (see comment), so caller can decide to retry immediately. Other discussion. > > Admittedly, these races are rare and I had to work really hard to produce > them. I'll try to find my testing mechanism. My concern is reintroducing > this abandoning of pageblocks. I have not looked further in your series > to see if this potentially addressed later. If not, then we should not > remove the return code. > Memory offlining could race with alloc_contig_range(), e.g., called when allocating gigantic pages, or when virtio-mem tries to unplug memory. The latter two could also race. We are getting more alloc_contig_range() users, which is why these races will become more relevant. I have no clue what you mean with "reintroducing this abandoning of pageblocks". All this patch is changing is not doing the dump_page() - or am I missing something important? -- Thanks, David / dhildenb ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
[PATCH v1 2/6] mm/page_isolation: don't dump_page(NULL) in set_migratetype_isolate()
Right now, if we have two isolations racing, we might trigger the WARN_ON_ONCE() and to dump_page(NULL), dereferencing NULL. Let's just return directly. In the future, we might want to report -EAGAIN to the caller instead, as this could indicate a temporary isolation failure only. Cc: Andrew Morton Cc: Michal Hocko Cc: Michael S. Tsirkin Signed-off-by: David Hildenbrand --- mm/page_isolation.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/mm/page_isolation.c b/mm/page_isolation.c index f6d07c5f0d34d..553b49a34cf71 100644 --- a/mm/page_isolation.c +++ b/mm/page_isolation.c @@ -29,10 +29,12 @@ static int set_migratetype_isolate(struct page *page, int migratetype, int isol_ /* * We assume the caller intended to SET migrate type to isolate. * If it is already set, then someone else must have raced and -* set it before us. Return -EBUSY +* set it before us. */ - if (is_migrate_isolate_page(page)) - goto out; + if (is_migrate_isolate_page(page)) { + spin_unlock_irqrestore(&zone->lock, flags); + return -EBUSY; + } /* * FIXME: Now, memory hotplug doesn't call shrink_slab() by itself. -- 2.26.2 ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization