From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49732C4363D for ; Thu, 24 Sep 2020 12:06:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4CF8423772 for ; Thu, 24 Sep 2020 12:06:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="r+2/xhDi" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4CF8423772 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 47DCA900024; Thu, 24 Sep 2020 08:06:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 42EFC900017; Thu, 24 Sep 2020 08:06:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 344CF900024; Thu, 24 Sep 2020 08:06:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id 1FDAD900017 for ; Thu, 24 Sep 2020 08:06:48 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id DA5F8180AD801 for ; Thu, 24 Sep 2020 12:06:47 +0000 (UTC) X-FDA: 77297828454.11.egg33_4a09c762715e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id AAAB9180F8B8B for ; Thu, 24 Sep 2020 12:06:47 +0000 (UTC) X-HE-Tag: egg33_4a09c762715e X-Filterd-Recvd-Size: 7558 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Thu, 24 Sep 2020 12:06:46 +0000 (UTC) Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08OC3hp4089660; Thu, 24 Sep 2020 08:06:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=pp1; bh=V2HPM/eFjC6UZ7YckSVpOnkHlLRlQCxKJD3TO9C078U=; b=r+2/xhDiGSbcvRbYkT/w/sKa9nPJT5apngrZYZ7th3cWEluWLCEEKJusNELHH4lAX/NB WJ+3yR8AA2eXDqYOuNe0OI0kuK6GR12M5c0d3/HQvGzVkgQw+wg3go15DCFT1yqUkyWB 3AGNDZ1RakQLF9v5Sr+fobcANImvMmE1j4QPG5iYQtRk2t/JXnLuNRu6iUr3T/Qvihzl /SFat/Vd7kxG5DjajWyLJ82kq8WkCucwflIpC9oyPd6EV3hFI/cCzbKhnIofuTnfAgsH 2nPZucg+qsf3TwTJB/TIlJg0ZOKeX0OFjXYKD8skrkGYZdrMzbXhthPa6BuFe7gI+bTo hw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 33rtnh11u2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 Sep 2020 08:06:45 -0400 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 08OC4Rhe093837; Thu, 24 Sep 2020 08:06:45 -0400 Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com with ESMTP id 33rtnh11sw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 Sep 2020 08:06:45 -0400 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 08OC2MTm029894; Thu, 24 Sep 2020 12:06:42 GMT Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by ppma06ams.nl.ibm.com with ESMTP id 33n98gw7tm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 24 Sep 2020 12:06:42 +0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 08OC6ebv30998850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 24 Sep 2020 12:06:40 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F1BAF5204E; Thu, 24 Sep 2020 12:06:39 +0000 (GMT) Received: from thinkpad (unknown [9.171.54.160]) by d06av21.portsmouth.uk.ibm.com (Postfix) with SMTP id 8A81552051; Thu, 24 Sep 2020 12:06:39 +0000 (GMT) Date: Thu, 24 Sep 2020 14:06:38 +0200 From: Gerald Schaefer To: Linus Torvalds Cc: Peter Xu , Heiko Carstens , Qian Cai , Alexander Gordeev , Vasily Gorbik , Christian Borntraeger , linux-s390 , Linux-MM , Linux Kernel Mailing List Subject: Re: BUG: Bad page state in process dirtyc0w_child Message-ID: <20200924140638.7bcb7765@thinkpad> In-Reply-To: <20200924000226.06298978@thinkpad> References: <20200916142806.GD7076@osiris> <20200922190350.7a0e0ca5@thinkpad> <20200923153938.5be5dd2c@thinkpad> <20200923233306.7c5666de@thinkpad> <20200924000226.06298978@thinkpad> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-09-24_08:2020-09-24,2020-09-24 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 suspectscore=2 spamscore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 mlxscore=0 mlxlogscore=999 impostorscore=0 phishscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009240095 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 24 Sep 2020 00:02:26 +0200 Gerald Schaefer wrote: > On Wed, 23 Sep 2020 14:50:36 -0700 > Linus Torvalds wrote: > > > On Wed, Sep 23, 2020 at 2:33 PM Gerald Schaefer > > wrote: > > > > > > Thanks, very nice walk-through, need some time to digest this. The TLB > > > aspect is interesting, and we do have our own __tlb_remove_page_size(), > > > which directly calls free_page_and_swap_cache() instead of the generic > > > batched approach. > > > > So I don't think it's the free_page_and_swap_cache() itself that is the problem. > > > > As mentioned, the actual pages themselves should be handled by the > > reference counting being atomic. > > > > The interrupt disable is really about just the page *tables* being > > free'd - not the final page level. > > > > So the issue is that at least on x86-64, we have the serialization > > that we will only free the page tables after a cross-CPU IPI has > > flushed the TLB. > > > > I think s390 just RCU-free's the page tables instead, which should fix it. > > > > So I think this is special, and s390 is very different from x86, but I > > don't think it's the problem. Ah of course, I got confused by freeing pagetable pages vs. the pages themselves. For the pagetable pages we actually use the generic tlb_remove_table_(sync_)one, including the IPI-synchronizing smp_call_function (CONFIG_MMU_GATHER_RCU_TABLE_FREE=y). The "s390 magic" then only starts in our own __tlb_remove_table, where we take care of the special 2K vs. 4K pagetable stuff. Thanks a lot for this very valuable abstract of "who is who and why" in pagetable memory management :-) > > > > In fact, I think you pinpointed the real issue: > > > > > Meanwhile, out of curiosity, while I still fail to comprehend commit > > > 09854ba94c6a ("mm: do_wp_page() simplification") in its entirety, there > > > is one detail that I find most confusing: the unlock_page() has moved > > > behind the wp_page_reuse(), while it was the other way round before. > > > > You know what? That was just a mistake, and I think you may actually > > have hit the real cause of the problem. > > > > It means that we keep the page locked until after we do the > > pte_unmap_unlock(), so now we have no guarantees that we hold the page > > referecne. > > > > And then we unlock it - while somebody else might be freeing it. > > > > So somebody is freeing a locked page just as we're unlocking it, and > > that matches the problem you see exactly: the debug thing will hit > > because the last free happened while locked, and then by the time the > > printout happens it has become unlocked so it doesn't show any more. > > > > Duh. > > > > Would you mind testing just moving the unlock_page() back to before > > the wp_page_reuse()? > > Sure, I'll give it a try running over the night again. It's all good now, no more occurrences with unlock_page() before wp_page_reuse().