Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp498243pxk; Thu, 1 Oct 2020 07:34:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxDjL0tkWtIq+G3tBH1yQjyw0zjl8CBzXvxZLtILYDCtqjG373kiG7MtFhBPbb5iJ4B53Jb X-Received: by 2002:a17:906:4f16:: with SMTP id t22mr8330136eju.40.1601562855535; Thu, 01 Oct 2020 07:34:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601562855; cv=none; d=google.com; s=arc-20160816; b=BujVxwp7iDoKm3N4KFjBJUoF4ohctfSYR6NTTig95Ejg1xx8JHPGaUqFpQN6R+IhtS D2CROKxmxDXRkkt1oN6WCE5qGDb5uusvyjUIOctb6JJJZWxQ+Jn1MCfQPI7oYobTtPxf yOS2AA0pxcErZIbInv3HdxqVUUSpryCOSsOISpHS1YASDnUXVVMhY0Zbe3r+JnyB5D5Y 4gyTopaGiggIaq8n6Awlpsdrp8/PY3RxKFRpaqs93fj+JXfK+n6ocUVqGEoCUeimu09y oJdX74JMMXPVpxsSgkfY9RKQATDVRFflzdGc3WoQkNLveXhh5fGDSRu63uPPJ/F6WTq1 mEZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=MT7eYQmEncoWFfXb3v2i0oegKhgFDremUCLyTZsLhEU=; b=stL8JCSFOEdhDNNjAu9XJs2DW4/ANyFBOS4zgg1IzmebFiRdhR75Gm8q4P/LAt2FCn 3X7o+UbVoYbf408WF6BgBXlyYxfee6gkKQQX07muNb53l/PHOkuGIDp5j7ZqvjJslJC3 cdiCYKJhwVey9eTPEyRaw8ZmTvX6ZKDAhJ8rafdj6E3sQscS0IMQOhLBqZhCA/C72vOj sPru+V8hrdVzM48tUGBDAfd2nKIfEaMFumfCc/lTWB2rD/oto3U2Sox7HNrpCYk9dqhK bUR40YcpOvIadYwZFreH9CCTH5OJpt7CQs4S2j2FuXgIiVaLy0TFLMcev8wVOomlw+/z 7eew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=M3RGHKIk; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r25si3558413eds.157.2020.10.01.07.33.50; Thu, 01 Oct 2020 07:34:15 -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=@redhat.com header.s=mimecast20190719 header.b=M3RGHKIk; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732407AbgJAOcY (ORCPT + 99 others); Thu, 1 Oct 2020 10:32:24 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:38129 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732299AbgJAOcY (ORCPT ); Thu, 1 Oct 2020 10:32:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1601562742; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MT7eYQmEncoWFfXb3v2i0oegKhgFDremUCLyTZsLhEU=; b=M3RGHKIk2q/7JK8/ECFX6Vc1wDjCRGgM/NxUUIwXCtEL/YzLnQ67P8xScGK5j6rAKL1ocL g9KLFT10D10inbVckukeHRO1+Z40AGN7gVHLgM6qw/RIG8A0oj3DkKsrkfII8Ye09mf61C jxE5+Jzt0/58MzdinLHaB3Ao7bdQ0P8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-593-3ey2_6RHMpaPr7bYlc1JGA-1; Thu, 01 Oct 2020 10:32:21 -0400 X-MC-Unique: 3ey2_6RHMpaPr7bYlc1JGA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8806DA3F5F; Thu, 1 Oct 2020 14:32:01 +0000 (UTC) Received: from optiplex-lnx (unknown [10.3.128.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 389FE19C59; Thu, 1 Oct 2020 14:31:59 +0000 (UTC) Date: Thu, 1 Oct 2020 10:31:57 -0400 From: Rafael Aquini To: "Huang, Ying" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org Subject: Re: [PATCH] mm: swapfile: avoid split_swap_cluster() NULL pointer dereference Message-ID: <20201001143157.GA1530324@optiplex-lnx> References: <20200923043459.GL795820@optiplex-lnx> <87sgb9oz1u.fsf@yhuang-dev.intel.com> <20200923130138.GM795820@optiplex-lnx> <87blhwng5f.fsf@yhuang-dev.intel.com> <20200924020928.GC1023012@optiplex-lnx> <877dsjessq.fsf@yhuang-dev.intel.com> <20200924063038.GD1023012@optiplex-lnx> <87tuvnd3db.fsf@yhuang-dev.intel.com> <20200924150833.GE1023012@optiplex-lnx> <87r1qqbkx5.fsf@yhuang-dev.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r1qqbkx5.fsf@yhuang-dev.intel.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 25, 2020 at 11:21:58AM +0800, Huang, Ying wrote: > Rafael Aquini writes: > >> Or, can you help to run the test with a debug kernel based on upstream > >> kernel. I can provide some debug patch. > >> > > > > Sure, I can set your patches to run with the test cases we have that tend to > > reproduce the issue with some degree of success. > > Thanks! > > I found a race condition. During THP splitting, "head" may be unlocked > before calling split_swap_cluster(), because head != page during > deferred splitting. So we should call split_swap_cluster() before > unlocking. The debug patch to do that is as below. Can you help to > test it? > > Best Regards, > Huang, Ying > > ------------------------8<---------------------------- > From 24ce0736a9f587d2dba12f12491c88d3e296a491 Mon Sep 17 00:00:00 2001 > From: Huang Ying > Date: Fri, 25 Sep 2020 11:10:56 +0800 > Subject: [PATCH] dbg: Call split_swap_clsuter() before unlock page during > split THP > > --- > mm/huge_memory.c | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index faadc449cca5..8d79e5e6b46e 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2444,6 +2444,12 @@ static void __split_huge_page(struct page *page, struct list_head *list, > > remap_page(head); > > + if (PageSwapCache(head)) { > + swp_entry_t entry = { .val = page_private(head) }; > + > + split_swap_cluster(entry); > + } > + > for (i = 0; i < HPAGE_PMD_NR; i++) { > struct page *subpage = head + i; > if (subpage == page) > @@ -2678,12 +2684,7 @@ int split_huge_page_to_list(struct page *page, struct list_head *list) > } > > __split_huge_page(page, list, end, flags); > - if (PageSwapCache(head)) { > - swp_entry_t entry = { .val = page_private(head) }; > - > - ret = split_swap_cluster(entry); > - } else > - ret = 0; > + ret = 0; > } else { > if (IS_ENABLED(CONFIG_DEBUG_VM) && mapcount) { > pr_alert("total_mapcount: %u, page_count(): %u\n", > -- > 2.28.0 > I left it running for several days, on several systems that had seen the crash hitting before, and no crashes were observed for either the upstream kernel nor the distro build 4.18-based kernel. I guess we can comfortably go with your patch. Thanks!