From patchwork Mon Nov 5 15:04:00 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zaslonko Mikhail X-Patchwork-Id: 10668399 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 9BBF81709 for ; Mon, 5 Nov 2018 15:06:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 89B9428707 for ; Mon, 5 Nov 2018 15:06:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7DD02287A6; Mon, 5 Nov 2018 15:06:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 007F428707 for ; Mon, 5 Nov 2018 15:06:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 122086B000D; Mon, 5 Nov 2018 10:06:35 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 0A8976B000E; Mon, 5 Nov 2018 10:06:35 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB2CF6B0010; Mon, 5 Nov 2018 10:06:34 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by kanga.kvack.org (Postfix) with ESMTP id A9DFA6B000D for ; Mon, 5 Nov 2018 10:06:34 -0500 (EST) Received: by mail-pg1-f197.google.com with SMTP id 18-v6so8699954pgn.4 for ; Mon, 05 Nov 2018 07:06:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id; bh=RI51RBXAWlWuMu7U34dYRBPtFISDxcHLg6PXlL4IqLk=; b=ItZVZBH0mQtIbpgjCljWPbFBG2HnFO4mOr08hDxsS0AFYR1ONTirMxEppNG1lEJnqo coQiRpzxPFjdiZ236n6w/IMV4B/sC5A2VoT0lBwG5YWTgalYySh3YeYv8MaCn/XufV7z dTETBerOdZz7EOvmrHSE2wUa5qC0zeKmG7kjPKXHTsW/YSHMSnuLeMe6B+8SmW/mLnvl fzg4uq6efI0FOuSHIKcvsPv+45WLcZk+sqLSZ+UJuQqnGskvt3zi3hqdO2HdNmiG9SZ4 QGBHa+audjT4Nxs3EU8MCY789YbcnXQSHD2XRSR0wYgpGqGKE7jgwAKr5cyQbpQrDHzY 7xkQ== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of zaslonko@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=zaslonko@linux.ibm.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com X-Gm-Message-State: AGRZ1gIn0UuzDUgLNObcSLmEurZ+BGz82cizXc/rUfd5mrr0hJuZyhQ3 SRVbiudZ1aZSa7yd+Avrso9yAez+8JCV4wn5B41iGxLwUKcez3aKAYLp9r2cDcqc5A1uXYrHTbt rlR+sir3z6ldcGTB0OKxHj66cbTIsABdw/od3T4apa5P6kvQfbzL90ik4oZZbv9oOHQ== X-Received: by 2002:a17:902:d705:: with SMTP id w5-v6mr21820273ply.11.1541430394338; Mon, 05 Nov 2018 07:06:34 -0800 (PST) X-Google-Smtp-Source: AJdET5ejirxole9ZiqwNcYhZLL8nRux61L94LsH44ONsjaQW502fHftqnO0EYfqN5U2vctOXACxw X-Received: by 2002:a17:902:d705:: with SMTP id w5-v6mr21820197ply.11.1541430393216; Mon, 05 Nov 2018 07:06:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541430393; cv=none; d=google.com; s=arc-20160816; b=jdxk+eBYX7RoHFEL791w6/Hyd9/Bltu0+7OqCuj1eekc1x7oM7NMR9Ufpa/n/VrPHu nwCdVc6ppiJWM60a2CpTo1ogqhYyOk/Xpg+CTBesZ2G4lia1+xGZ/J+7a/5O0PcvDcm5 Tzv6hI0ExVqS4ZNVGCyh0vFX2L/kaEe7u0QWYOSaL2fauYdT5OVQ+7BIWwlZ+xZx8Bn+ fwi1QzWnE4iAWklXP/Fl//xnr2xK+v5tveY8vaPHDiN3cNQtwsorEEBg1wCrgOOSK2tV kngTHBccrPFOU7sF8WlrCT42diP9sdDnO0O9Gxq7AMUKX6BBL196ABNHaVJ+XkDZmBfm bdQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:subject:cc:to:from; bh=RI51RBXAWlWuMu7U34dYRBPtFISDxcHLg6PXlL4IqLk=; b=JkwA0tkku6+48zywWF0fuK0aXlaYiRG7CtTGemirEWoorSZ/f/zkDOrrkgcVrwuHnu wvMtcmekem+eMblJZGySzuFxT4nnsymq9kFqEHYQKVHHN3/fIy6G1r+fD3YIg/DCRSTO u1wghuKOMj0UVfpMVkYx4JaINAccR6/f38di8u/KR6v2z0AawmTkwIXgMQwWYKIiz+ws UhD1txArRNvoUABG0zJ4dkYr1UqixLy1Lls3IsTUmfPXWldDsgFYirdzrrdMtD7dSPNI 2JkEOdbDLysxPoP7q/xET6b54wMdXcEOIqlY4eDDuMIV2o4/GBOqT9YYdvxXLClNmhGw FHag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of zaslonko@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=zaslonko@linux.ibm.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com. [148.163.156.1]) by mx.google.com with ESMTPS id e129-v6si9184815pfg.205.2018.11.05.07.06.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 07:06:33 -0800 (PST) Received-SPF: pass (google.com: domain of zaslonko@linux.ibm.com designates 148.163.156.1 as permitted sender) client-ip=148.163.156.1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of zaslonko@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=zaslonko@linux.ibm.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wA5F64iO002181 for ; Mon, 5 Nov 2018 10:06:32 -0500 Received: from e06smtp03.uk.ibm.com (e06smtp03.uk.ibm.com [195.75.94.99]) by mx0a-001b2d01.pphosted.com with ESMTP id 2njpy841cf-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 05 Nov 2018 10:06:27 -0500 Received: from localhost by e06smtp03.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 5 Nov 2018 15:04:06 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp03.uk.ibm.com (192.168.101.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 5 Nov 2018 15:04:02 -0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id wA5F41G37012834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 5 Nov 2018 15:04:01 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 951C1AE057; Mon, 5 Nov 2018 15:04:01 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 57EAEAE059; Mon, 5 Nov 2018 15:04:01 +0000 (GMT) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Mon, 5 Nov 2018 15:04:01 +0000 (GMT) From: Mikhail Zaslonko To: akpm@linux-foundation.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org, Pavel.Tatashin@microsoft.com, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, gerald.schaefer@de.ibm.com, zaslonko@linux.ibm.com Subject: [PATCH v2 0/1] memory_hotplug: fix the panic when memory end is not Date: Mon, 5 Nov 2018 16:04:00 +0100 X-Mailer: git-send-email 2.16.4 X-TM-AS-GCONF: 00 x-cbid: 18110515-0012-0000-0000-000002C3A4A8 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18110515-0013-0000-0000-000020F7E3E2 Message-Id: <20181105150401.97287-1-zaslonko@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-05_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811050139 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: X-Virus-Scanned: ClamAV using ClamSMTP This patch refers to the older thread: https://marc.info/?t=153658306400001&r=1&w=2 I have tried to take the approaches suggested in the discussion like simply ignoring unaligned memory to section memory much earlier or initializing struct pages beyond the "end" but both had issues. First I tried to ignore unaligned memory early by adjusting memory_end value. But the thing is that kernel mem parameter parsing and memory_end calculation take place in the architecture code and adjusting it afterwards in common code might be too late in my view. Also with this approach we might lose the memory up to the entire section(256Mb on s390) just because of unfortunate alignment. Another approach was to fix memmap_init() and initialize struct pages beyond the end. Since struct pages are allocated section-wise we can try to round the size parameter passed to the memmap_init() function up to the section boundary thus forcing the mapping initialization for the entire section. But then it leads to another VM_BUG_ON panic due to zone_spans_pfn() sanity check triggered for the first page of each page block from set_pageblock_migratetype() function: page dumped because: VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn)) Call Trace: ([<00000000003013f8>] set_pfnblock_flags_mask+0xe8/0x140) [<00000000003014aa>] set_pageblock_migratetype+0x5a/0x70 [<0000000000bef706>] memmap_init_zone+0x25e/0x2e0 [<00000000010fc3d8>] free_area_init_node+0x530/0x558 [<00000000010fcf02>] free_area_init_nodes+0x81a/0x8f0 [<00000000010e7fdc>] paging_init+0x124/0x130 [<00000000010e4dfa>] setup_arch+0xbf2/0xcc8 [<00000000010de9e6>] start_kernel+0x7e/0x588 [<000000000010007c>] startup_continue+0x7c/0x300 Last Breaking-Event-Address: [<00000000003013f8>] set_pfnblock_flags_mask+0xe8/0x1401 We might ignore this check for the struct pages beyond the "end" but I'm not sure about further implications. For now I suggest to stay with my original proposal fixing specific functions for memory hotplug sysfs handlers. Changes v1 -> v2: * Expanded commit message to show both failing scenarious. * Use 'pfn + i' instead of 'pfn' for zone_spans_pfn() check within test_pages_in_a_zone() function thus taking CONFIG_HOLES_IN_ZONE into consideration. Mikhail Zaslonko (1): memory_hotplug: fix the panic when memory end is not on the section boundary mm/memory_hotplug.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-)