Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3291294pxk; Mon, 21 Sep 2020 09:50:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzXDm5GKKuEEW9tXrvINnax4+7hzahiaYTj4Kq0+dieWaeTLv5NjKO/0CkrHXetGkA7s9aC X-Received: by 2002:a17:906:fcc7:: with SMTP id qx7mr391889ejb.254.1600707036542; Mon, 21 Sep 2020 09:50:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600707036; cv=none; d=google.com; s=arc-20160816; b=U+qvcwOIYCywu5nJWAAyIf9LCxpZ9ROnqNFMCnStDko2y/wvR1kCfvpTmc6W3g0HA3 5gntr2OieLvt/YjWLiANcU9PdMLgpbxtfJDY1sOt6kqcX5rK+QkHO1p53r+aaHdzFrNZ FQjaRTeKp7axRYYxOEp0VgSgU7bRMZMKSzna0An0awR/e3Bb4k7uemP58zGKfsURpRpL bPjEJWh7qRxfA33qXSVQMkx8o59zlDU0hbTZMT28PXNfwqzVziA5cx0/ymVykZLzcZK5 Kiod/5ksuyurgfMNK68j69DPQLscrZjnmQEntbko8bOcLxA2+2c5XALheE2nHAX2zCIt zVBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=QTP1o7a8AWs9agfK8noE7y57+uy52IpNgdmBnSZngBE=; b=E3Zc0qZpIdnynBwD6MHBCEWe+FEbrq+0xK2FK8uilNfABsAOfRgowAeBTzwgOwiMua h5nC2lRRJTGuxNcfr/aSOJLk309einZ9728h8BxDMk6D/M7JvMp7VSBDC33J9rTiwhT8 wsdoJY7OKy5WUZbCd9ilbtA9GkY/5deuZ8e8wae2SoFxbHwKDhJXMlVaCw7e4apqZCeI XEyYLIILAxtEh9HbyCGvQPCYzeTk1mIYa88hUGsGPZ1FQpO+wQPWUIv64DUtsKpmX+GG ZwhMplqXCurl4K6U7kVsucJGNxzWoPDpT8UE6vUWpzVgypBYxLvaDPybZMdv55myH0KL ltow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=g7jWwC6g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id pj4si8679374ejb.628.2020.09.21.09.50.12; Mon, 21 Sep 2020 09:50:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=g7jWwC6g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729047AbgIUQrV (ORCPT + 99 others); Mon, 21 Sep 2020 12:47:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:54100 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729729AbgIUQrT (ORCPT ); Mon, 21 Sep 2020 12:47:19 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 279222223E; Mon, 21 Sep 2020 16:47:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600706838; bh=t5xLQdCglEC5UqWUa3fmgA0Doh7QaSVqI1DeDQ+pLpw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g7jWwC6gL/RAxt+HJwdf3IqcLaN16PH67Zesoc6HopaY86l/VPIwj1nX0+A/wty1Y IWcz/CcM6RNTls5ZCZukLQpvEjsqhxQJsGSftAmk9pTG7ZZATkJT5fK9gaCadHD/Tg OI45J4OZsmuVCSo9oxLt1y6up5rB7RKIspfGlm0M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pavel Tatashin , Andrew Morton , David Rientjes , Vlastimil Babka , Michal Hocko , David Hildenbrand , Oscar Salvador , Wei Yang , Linus Torvalds Subject: [PATCH 5.8 114/118] mm/memory_hotplug: drain per-cpu pages again during memory offline Date: Mon, 21 Sep 2020 18:28:46 +0200 Message-Id: <20200921162041.686629549@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200921162036.324813383@linuxfoundation.org> References: <20200921162036.324813383@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Pavel Tatashin commit 9683182612214aa5f5e709fad49444b847cd866a upstream. There is a race during page offline that can lead to infinite loop: a page never ends up on a buddy list and __offline_pages() keeps retrying infinitely or until a termination signal is received. Thread#1 - a new process: load_elf_binary begin_new_exec exec_mmap mmput exit_mmap tlb_finish_mmu tlb_flush_mmu release_pages free_unref_page_list free_unref_page_prepare set_pcppage_migratetype(page, migratetype); // Set page->index migration type below MIGRATE_PCPTYPES Thread#2 - hot-removes memory __offline_pages start_isolate_page_range set_migratetype_isolate set_pageblock_migratetype(page, MIGRATE_ISOLATE); Set migration type to MIGRATE_ISOLATE-> set drain_all_pages(zone); // drain per-cpu page lists to buddy allocator. Thread#1 - continue free_unref_page_commit migratetype = get_pcppage_migratetype(page); // get old migration type list_add(&page->lru, &pcp->lists[migratetype]); // add new page to already drained pcp list Thread#2 Never drains pcp again, and therefore gets stuck in the loop. The fix is to try to drain per-cpu lists again after check_pages_isolated_cb() fails. Fixes: c52e75935f8d ("mm: remove extra drain pages on pcp list") Signed-off-by: Pavel Tatashin Signed-off-by: Andrew Morton Acked-by: David Rientjes Acked-by: Vlastimil Babka Acked-by: Michal Hocko Acked-by: David Hildenbrand Cc: Oscar Salvador Cc: Wei Yang Cc: Link: https://lkml.kernel.org/r/20200903140032.380431-1-pasha.tatashin@soleen.com Link: https://lkml.kernel.org/r/20200904151448.100489-2-pasha.tatashin@soleen.com Link: http://lkml.kernel.org/r/20200904070235.GA15277@dhcp22.suse.cz Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/memory_hotplug.c | 14 ++++++++++++++ mm/page_isolation.c | 8 ++++++++ 2 files changed, 22 insertions(+) --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1557,6 +1557,20 @@ static int __ref __offline_pages(unsigne /* check again */ ret = walk_system_ram_range(start_pfn, end_pfn - start_pfn, NULL, check_pages_isolated_cb); + /* + * per-cpu pages are drained in start_isolate_page_range, but if + * there are still pages that are not free, make sure that we + * drain again, because when we isolated range we might + * have raced with another thread that was adding pages to pcp + * list. + * + * Forward progress should be still guaranteed because + * pages on the pcp list can only belong to MOVABLE_ZONE + * because has_unmovable_pages explicitly checks for + * PageBuddy on freed pages on other zones. + */ + if (ret) + drain_all_pages(zone); } while (ret); /* Ok, all of our target is isolated. --- a/mm/page_isolation.c +++ b/mm/page_isolation.c @@ -170,6 +170,14 @@ __first_valid_page(unsigned long pfn, un * pageblocks we may have modified and return -EBUSY to caller. This * prevents two threads from simultaneously working on overlapping ranges. * + * Please note that there is no strong synchronization with the page allocator + * either. Pages might be freed while their page blocks are marked ISOLATED. + * In some cases pages might still end up on pcp lists and that would allow + * for their allocation even when they are in fact isolated already. Depending + * on how strong of a guarantee the caller needs drain_all_pages might be needed + * (e.g. __offline_pages will need to call it after check for isolated range for + * a next retry). + * * Return: the number of isolated pageblocks on success and -EBUSY if any part * of range cannot be isolated. */