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=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 B9627C4360C for ; Fri, 27 Sep 2019 21:28:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 666E72075D for ; Fri, 27 Sep 2019 21:28:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=lca.pw header.i=@lca.pw header.b="rB6Ae8Gs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 666E72075D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lca.pw Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F36848E0005; Fri, 27 Sep 2019 17:28:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC06B8E0001; Fri, 27 Sep 2019 17:28:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D86568E0005; Fri, 27 Sep 2019 17:28:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id B184F8E0001 for ; Fri, 27 Sep 2019 17:28:09 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 5039F81D9 for ; Fri, 27 Sep 2019 21:28:09 +0000 (UTC) X-FDA: 75981988698.29.actor20_643c885143622 X-HE-Tag: actor20_643c885143622 X-Filterd-Recvd-Size: 6201 Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Fri, 27 Sep 2019 21:28:08 +0000 (UTC) Received: by mail-qt1-f193.google.com with SMTP id l3so9101029qtr.4 for ; Fri, 27 Sep 2019 14:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=OSzYm24kMm+3qsYyi0PMA9ARrI4D/MfOEwhnPkS6YeA=; b=rB6Ae8GsgMKyXP2kIYlZdVkMQw5z5AgLQJ2JqQdEYq6qXHOG3NWtz3nhkxhP3Eq3Ah DSwDFvsXL8szTF0jsaA1qBVp/X6Lr1RfD0mFJYkQDd2S6sXz6BVDRB06kySbFyh365z+ Ogzn+eX3gQqdXZZxxbdj41XasaOfqyp/leQkZlAwnUrfs7uRHkkedxTCCrexo4Cnd67v zKXOkUjrEy+MZsg4YNJa0Ova2ssP7aAfIbEcTGdMv/g5vfS7Htk//ie7vX6zCO+USuuX kQUCxeDVZgr4KxJy4i7t9Ntu6eBel9ktGtdZw1eKKK3vGGhOeYivJsVxNrJmIUKTb4fj ZfOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=OSzYm24kMm+3qsYyi0PMA9ARrI4D/MfOEwhnPkS6YeA=; b=cNXbpP9SWzoH/umZi8AxKo5H7ZIr6jaiHYq6tCYg+oMCASQ9lyx7ZzEWnqMdVpT/1Y qsLuYMCBYGBpRC7+GwplluMTlVhwARUxs4ZK6cTswtiGMKEda3dGlWtNlqpdR4R0wNqe HspB2E2wIFlmnYNAvfTj+TzCCjZyBxbRusISAGT3IIvDAgtm+iqJFinhOUHssrSnvI0c MeZnKkO+/Zi7kLBzAPixRos26D8tksQHXgXQf5sCS7oOmr+xaLnP3TtqxmHZEw23mrcb o+z9ragu2d45iq1zK1GauboKrXtuJnfg1lGMT9ERI4AycELR2N5Xjfo5Cw5UcY0Pl4wq DYgA== X-Gm-Message-State: APjAAAXp9peeyXwjSt4L58GwQSHzX0Hoka39YFpJKsiMMhCT61S/dVj3 SIZnrutwMULFzDXvHRomYVrLhA== X-Google-Smtp-Source: APXvYqwufZybaXtm0KCuPg3uZ3BPhqW+oT1dBLOwS6HEHY04KEDFQUFlFH14fTnbK7+h1k4NFQvDvQ== X-Received: by 2002:ac8:301b:: with SMTP id f27mr11837429qte.83.1569619688095; Fri, 27 Sep 2019 14:28:08 -0700 (PDT) Received: from dhcp-41-57.bos.redhat.com (nat-pool-bos-t.redhat.com. [66.187.233.206]) by smtp.gmail.com with ESMTPSA id m14sm1636640qki.27.2019.09.27.14.28.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Sep 2019 14:28:07 -0700 (PDT) Message-ID: <1569619686.5576.242.camel@lca.pw> Subject: Re: [PATCH] mm/page_alloc: fix a crash in free_pages_prepare() From: Qian Cai To: Andrew Morton Cc: heiko.carstens@de.ibm.com, gor@linux.ibm.com, borntraeger@de.ibm.com, linux-s390@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Date: Fri, 27 Sep 2019 17:28:06 -0400 In-Reply-To: <20190927140222.6f7d0a41b9e734053ee911b9@linux-foundation.org> References: <1569613623-16820-1-git-send-email-cai@lca.pw> <20190927140222.6f7d0a41b9e734053ee911b9@linux-foundation.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-10.el7) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.043556, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 2019-09-27 at 14:02 -0700, Andrew Morton wrote: > On Fri, 27 Sep 2019 15:47:03 -0400 Qian Cai wrote: >=20 > > On architectures like s390, arch_free_page() could mark the page unus= ed > > (set_page_unused()) and any access later would trigger a kernel panic= . > > Fix it by moving arch_free_page() after all possible accessing calls. > >=20 > > Hardware name: IBM 2964 N96 400 (z/VM 6.4.0) > > Krnl PSW : 0404e00180000000 0000000026c2b96e > > (__free_pages_ok+0x34e/0x5d8) > > R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 E= A:3 > > Krnl GPRS: 0000000088d43af7 0000000000484000 000000000000007c > > 000000000000000f > > 000003d080012100 000003d080013fc0 0000000000000000 > > 0000000000100000 > > 00000000275cca48 0000000000000100 0000000000000008 > > 000003d080010000 > > 00000000000001d0 000003d000000000 0000000026c2b78a > > 000000002717fdb0 > > Krnl Code: 0000000026c2b95c: ec1100b30659 risbgn %r1,%r1,0,179,6 > > 0000000026c2b962: e32014000036 pfd 2,1024(%r1) > > #0000000026c2b968: d7ff10001000 xc 0(256,%r1),0(%r1) > > >0000000026c2b96e: 41101100 la %r1,256(%r1) > > 0000000026c2b972: a737fff8 brctg %r3,26c2b962 > > 0000000026c2b976: d7ff10001000 xc 0(256,%r1),0(%r1) > > 0000000026c2b97c: e31003400004 lg %r1,832 > > 0000000026c2b982: ebff1430016a asi 5168(%r1),-1 > > Call Trace: > > __free_pages_ok+0x16a/0x5d8) > > memblock_free_all+0x206/0x290 > > mem_init+0x58/0x120 > > start_kernel+0x2b0/0x570 > > startup_continue+0x6a/0xc0 > > INFO: lockdep is turned off. > > Last Breaking-Event-Address: > > __free_pages_ok+0x372/0x5d8 > > Kernel panic - not syncing: Fatal exception: panic_on_oops > > 00: HCPGIR450W CP entered; disabled wait PSW 00020001 80000000 000000= 00 > > 26A2379C > >=20 > > ... > >=20 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -1175,11 +1175,11 @@ static __always_inline bool free_pages_prepar= e(struct page *page, > > debug_check_no_obj_freed(page_address(page), > > PAGE_SIZE << order); > > } > > - arch_free_page(page, order); > > if (want_init_on_free()) > > kernel_init_free_pages(page, 1 << order); > > =20 > > kernel_poison_pages(page, 1 << order, 0); > > + arch_free_page(page, order); > > if (debug_pagealloc_enabled()) > > kernel_map_pages(page, 1 << order, 0); >=20 > AFAICT the meticulously undocumented s390 set_page_unused() will cause > there to be a fault if anyone tries to access the page contents, yes? Yes. >=20 > So I think you've moved the arch_free_page() to be after the final > thing which can access page contents, yes? If so, we should have a > comment in free_pages_prepare() to attmept to prevent this problem from > reoccurring as the code evolves? Right, something like this above arch_free_page() there? /* * It needs to be just above=C2=A0kernel_map_pages(), as s390 could mark = those * pages unused and then trigger a fault when accessing. */