Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp364662pxk; Thu, 24 Sep 2020 07:28:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwLafP5zKqApf+GiewVBisbs3bi3p3SiN8mYfrS9HZzntERytejF56l69EevzurPohvoLOF X-Received: by 2002:a17:906:8401:: with SMTP id n1mr143445ejx.215.1600957737163; Thu, 24 Sep 2020 07:28:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600957737; cv=none; d=google.com; s=arc-20160816; b=J005aYJ2FgEnPBM2bNXVyzBKaDr67L7eOWsKIIlg3+1Ge4cf5ZDgh9ZZUGY4zs9iEU awAX4frQrs9Ij9G7kdapHch9my3jO/Ypa8fu+gnEhd5YKBsiRA2gs8EPXD0cqE8oAX/Y jl1wiiI2/PSKTHfFFV+kBVCgBt6Px8HGWuJ4vRWl3Bzr1JZarl6IvJ4Qm4DLio1eNuG5 /HgBdR8MxBlBi5URY6OyFe3jQ21KxCP3EFRgKbE8jwjzN3ZnmpgzNucT4MpqTDWApaLr pAJTpe9nK7OXftSHemVv5GUnKQp1XnIzuGrBPWxXykUanhJSdQFG17d0eBMvxjAGn1QU jbDw== 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 :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=hu1tCxnKxl+dwAXfqA7UI8WgDO2vf/liHqel4NLmjzk=; b=EZ+hN98D+vKKfQ6oqGMwzImWuuWeu0bKsMQKSqZ3a2vkNZBNU7sXLNQK50oPtbvmt4 HosGCYC3H9t6I6yAnyNReVHVHcORG5S+KU+hkcBgCzoCoN/W6INWlQjMudGOzqi2VraN sI1+G52hepJB8hu0oyEbV/wF9nbBaRyH782T3xLyx9PMUj9OxPgMW8Y9xgBTtxcWHCAN j7fa8s2xom+XQRgIGrpscGrcObABxLo6lJPHRPzRChMuO/vu6zZlk30UWQnhQcfVdG8k lXZSt4pSrtF9TefnMa7JpIslHtMmdlhljsI1k4ge8qXfcw5+Vq/SugJ6AfcVLa9n21M3 Qp7w== ARC-Authentication-Results: i=1; mx.google.com; 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=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j15si2095618ejs.51.2020.09.24.07.28.33; Thu, 24 Sep 2020 07:28:57 -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; 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=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728253AbgIXO1f (ORCPT + 99 others); Thu, 24 Sep 2020 10:27:35 -0400 Received: from out30-130.freemail.mail.aliyun.com ([115.124.30.130]:35865 "EHLO out30-130.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728064AbgIXO1f (ORCPT ); Thu, 24 Sep 2020 10:27:35 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R201e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04400;MF=alex.shi@linux.alibaba.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_---0U9zEpE4_1600957646; Received: from IT-FVFX43SYHV2H.lan(mailfrom:alex.shi@linux.alibaba.com fp:SMTPD_---0U9zEpE4_1600957646) by smtp.aliyun-inc.com(127.0.0.1); Thu, 24 Sep 2020 22:27:27 +0800 Subject: Re: BUG: Bad page state in process dirtyc0w_child To: Qian Cai , Gerald Schaefer , Linus Torvalds , Peter Xu Cc: Heiko Carstens , Alexander Gordeev , Vasily Gorbik , Christian Borntraeger , linux-s390@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20200916142806.GD7076@osiris> <20200922190350.7a0e0ca5@thinkpad> <20200923153938.5be5dd2c@thinkpad> <76fef5dfd8efdb4130e41d1811b2a78ce39c8b0d.camel@redhat.com> From: Alex Shi Message-ID: <4bf5597b-2466-29f3-e855-920d5632536f@linux.alibaba.com> Date: Thu, 24 Sep 2020 22:25:13 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <76fef5dfd8efdb4130e41d1811b2a78ce39c8b0d.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2020/9/24 上午10:06, Qian Cai 写道: > On Wed, 2020-09-23 at 15:39 +0200, Gerald Schaefer wrote: >> OK, I can now reproduce this, and unfortunately also with the gup_fast >> fix, so it is something different. Bisecting is a bit hard, as it will >> not always show immediately, sometimes takes up to an hour. >> >> Still, I think I found the culprit, merge commit b25d1dc9474e "Merge >> branch 'simplify-do_wp_page'". Without those 4 patches, it works fine, >> running over night. >> >> Not sure why this only shows on s390, should not be architecture-specific, >> but we do often see subtle races earlier than others due to hypervisor >> impact. > > Apparently, someone can reproduce something similar on x86 as well: > > https://lore.kernel.org/linux-mm/c41149a8-211e-390b-af1d-d5eee690fecb@linux.alibaba.com/ > > Probably, Alex could revert the bad commits and confirm it there. > >> >> The first commit 09854ba94c6a ("mm: do_wp_page() simplification") already yes, after revert this commit, the BUG disappears. Thanks Alex >> introduces this error. The dirtyc0w_child test seems to play with cow >> and racing madvise(MADV_DONTNEED), but I have not yet fully understood >> it and also not the changes from commit 09854ba94c6a. As Linus already >> mentioned in the merge commit message, this is some bad timing for such >> a change, so I don't want to delay this further with trying to understand >> it better before reporting. Maybe Peter or Linus can spot some obvious >> issue. >> >> One thing that seems strange to me is that the page flags from the >> bad page state output are (uptodate|swapbacked), see below, or >> (referenced|uptodate|dirty|swapbacked) in the original report. But IIUC, >> that should not qualify for the "PAGE_FLAGS_CHECK_AT_FREE flag(s) set" >> reason. So it seems that the flags have changed between check_free_page() >> and __dump_page(), which would be very odd. Or maybe some issue with >> compound pages, because __dump_page() looks at head->flags. >> >> [ 1863.237707] BUG: Bad page state in process dirtyc0w_child pfn:58527d >> [ 1863.237721] page:000000008866956b refcount:0 mapcount:0 >> mapping:0000000000000000 index:0x0 pfn:0x58527d >> [ 1863.237727] flags: 0x3ffff00000080004(uptodate|swapbacked) >> [ 1863.237734] raw: 3ffff00000080004 0000000000000100 0000000000000122 >> 0000000000000000 >> [ 1863.237738] raw: 0000000000000000 0000000000000000 ffffffff00000000 >> 0000000000000000 >> [ 1863.237742] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set >> [ 1863.237745] Modules linked in: >> [ 1863.237752] CPU: 16 PID: 9074 Comm: dirtyc0w_child Tainted: >> G B 5.9.0-rc6-00020-geff48ddeab78-dirty #104 >> [ 1863.237756] Hardware name: IBM 3906 M03 703 (LPAR) >> [ 1863.237759] Call Trace: >> [ 1863.237768] [<0000000000115f28>] show_stack+0x100/0x158 >> [ 1863.237775] [<000000000096b41a>] dump_stack+0xa2/0xd8 >> [ 1863.237781] [<00000000003d497c>] bad_page+0xdc/0x140 >> [ 1863.237785] [<00000000003d5b62>] free_pcp_prepare+0x31a/0x360 >> [ 1863.237789] [<00000000003d906a>] free_unref_page+0x32/0xb8 >> [ 1863.237794] [<00000000003b05f4>] zap_p4d_range+0x64c/0xcf8 >> [ 1863.237797] [<00000000003b0e7a>] unmap_page_range+0x9a/0x110 >> [ 1863.237801] [<00000000003b0f84>] unmap_single_vma+0x94/0x100 >> [ 1863.237805] [<00000000003b14c2>] zap_page_range+0x14a/0x1f0 >> [ 1863.237809] [<00000000003e3a24>] do_madvise+0x75c/0x918 >> [ 1863.237812] [<00000000003e3c06>] __s390x_sys_madvise+0x26/0x38 >> [ 1863.237817] [<0000000000d280d4>] system_call+0xe0/0x2c0 >> [ 1863.237820] INFO: lockdep is turned off. >>