Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp4646295pxb; Tue, 31 Aug 2021 09:52:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwBXwEoKBVrgX4cmhQmuxl+XpyJXagI2nJWGyfj7wCGOdd2GraHs+E3spToQNFHSwxr+9sk X-Received: by 2002:a92:6e12:: with SMTP id j18mr21810986ilc.243.1630428778347; Tue, 31 Aug 2021 09:52:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630428778; cv=none; d=google.com; s=arc-20160816; b=CSEsSUy3aE8Wwqxf3QrGcOMp7mw7A/2+u7rYV9ZjMarA5ZZEpPxDCTnQK94pXnhAzN +Da9uYGDhOzBJ1UZiuScSTCpMBjtSLKoLnS2wz0lEjDIPIpqKZpKYYIoL+f1B2ue5haf CAU9DyRmgDOsZSsHUOMOdg43kq08A5UoYlGGlB8kNf35c+K9ETTti6FWf+AuLELOA1S2 4p1KFZH3VGEq3WlSoSodEvSpTZLB4nAdpXl0JIPQANLb9VlxsnMYhIG4uof1Ftx8K96J qjiss12HJX5TftONXPylBVOD4wthbCRxJiS6zLvGSJowUCB/eHxR3sCn2ZbxK2KGJm8b Mb7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature:dkim-signature; bh=OklJGxSi0BbSbVaTpes0b4IBJRwo4fxs/JZP6qZD18I=; b=0pc3AEDOz/uveshQWrihCeLdH411BVvmItam6LitJTTUr7KTQY4aaJ23OnSL+F24ej LiOP/Ttlf0OswAx9k4CM23krXJI4lFCe+aicXJ8vpsGM8y7jPnB07qcE/VokUSPPyWRe q/bz85Vm9iCACQm6WMRY2YEIlINzrrcRRa6hncyZWz+L9zAQqhnvC3B96h9H5aUV6NtI hzaZeeW5Sf5zRbOhM3ylpxpBntj+x0su9xqW9kB1wKjsYEsxbYiuEsS9t97+OoL4x9Rs aDe1B3LK3ECZe+r3ccMomKnP0voyIQ4b42P4gh8+zZyKzr6ejY0mHNz7S1HB/5GThpS5 /2ww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=2NTsRNKL; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=EIsWg9jY; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m9si18969604iow.85.2021.08.31.09.52.45; Tue, 31 Aug 2021 09:52:58 -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=@suse.cz header.s=susede2_rsa header.b=2NTsRNKL; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=EIsWg9jY; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240345AbhHaQw0 (ORCPT + 99 others); Tue, 31 Aug 2021 12:52:26 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:43258 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240264AbhHaQwY (ORCPT ); Tue, 31 Aug 2021 12:52:24 -0400 Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 07A9E222C7; Tue, 31 Aug 2021 16:51:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1630428684; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OklJGxSi0BbSbVaTpes0b4IBJRwo4fxs/JZP6qZD18I=; b=2NTsRNKLu2TQozUQFmb6kqQ9YjVWwPKjLGyEAfxXNEYB0RR7tM/+K0AkfN6iXnz2hfqHgm nch9cMtAgEfKADPOR62XhxwPLOQP9dzu4PsOMfI4Z8SZVJyDpAGY8uCc3j2JQmL6c0mrSk yT08R6avt4HbpqNBC3fJZGRLwdSeyFU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1630428684; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OklJGxSi0BbSbVaTpes0b4IBJRwo4fxs/JZP6qZD18I=; b=EIsWg9jYEpTYgfPXmleG5avQ8CrvUU7pNqWnnrqeSwUnluIZh+gDBSR8+aU2n8WXCR1tvU vwfa5eC2gRYRTdDg== Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id DF851131F5; Tue, 31 Aug 2021 16:51:23 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id xnt/NQteLmGSXQAAGKfGzw (envelope-from ); Tue, 31 Aug 2021 16:51:23 +0000 Message-ID: <11357114-eb6e-39a6-b16d-5e380f770943@suse.cz> Date: Tue, 31 Aug 2021 18:51:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.0.3 Subject: Re: Stuck looping on list_empty(list) in free_pcppages_bulk() Content-Language: en-US To: Sultan Alsawaf , linux-mm@kvack.org Cc: mhocko@suse.com, mgorman@techsingularity.net, akpm@linux-foundation.org, linux-kernel@vger.kernel.org References: From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/31/21 01:12, Sultan Alsawaf wrote: > With some more gdb digging, I found that the `count` variable was stored in %ESI > at the time of the stall. According to register dump in the splat, %ESI was 7. > > It looks like, for some reason, the pcp count was 7 higher than the number of > pages actually present in the pcp lists. > > I tried to find some way that this could happen, but the only thing I could > think of was that maybe an allocation had both __GFP_RECLAIMABLE and > __GFP_MOVABLE set in its gfp mask, in which case the rmqueue() call in > get_page_from_freelist() would pass in a migratetype equal to MIGRATE_PCPTYPES > and then pages could be added to an out-of-bounds pcp list while still > incrementing the overall pcp count. This seems pretty unlikely though. As > another side note, it looks like there's nothing stopping this from occurring; > there's only a VM_WARN_ON() in gfp_migratetype() that checks if both bits are > set. > > Any ideas on what may have happened here, or a link to a commit that may have > fixed this issue in newer kernels, would be much appreciated. Does the kernel have commit 88e8ac11d2ea3 backported? If not, and there were memory hotplug operations happening, the infinite loop could happen. If that commit was not backported, and instead 5c3ad2eb7104 was backported, possibly there are more scenarios outside hotplug that can cause trouble. > Thanks, > Sultan >