Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1501058imm; Mon, 3 Sep 2018 02:02:11 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZInLjGYqKzJYWIR4pOLxUw2S9Pbwj3R5Yu8vxrXhi4CxaI5VsjuRXSun1j7+0THRZ0MXNC X-Received: by 2002:a63:a54f:: with SMTP id r15-v6mr25242891pgu.336.1535965331784; Mon, 03 Sep 2018 02:02:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535965331; cv=none; d=google.com; s=arc-20160816; b=EVASe6x1Atq24wasQGOGpCxlqooxGLabBB3l/vv1lbFizcNQr/AVt59S+r2atVXR6o ILbE8MDwzj1h0W5mdtnBDNUUg7hFxpoLyPRnrAf6JLI1X8y8ZJeBjKM/T4CR07hF+S8U Zx2NOh2vHqtKlhwwYSaj9eT+vdnYRXRCGWmQ8Jh8ULzAN8wMcb6kgZsj05io1zgJVxzK xd7EzKYdBNdze2RhaWW6OXE5X3ojh1V3eSs2fmUcSXpzHWTOPcQ9YYepAnymckVbl/qJ CiLwMwfyNiqP1EhlLU50npX1Yny7peROHG1PgkhXfBjXKWQmI+sXmm+v9m6wAvGPxBmI sKLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=Uyq57O6NT4ENgMuupAPJStv1rezVgtAxxCX/KW+58mE=; b=0/H1BjfbsehaH644RTPi38UxdPG6caUoXsNK9JN+r1T/RLPwbwzkSKaPfIvVZgz7aF Xf7NvTafah0feo1uGmG8I1cm+isNZHcaRZd8RkkHp3/3c9VHjVrLDYBHT3AWVkAD7ITe DGtmL1PKrSK9rl3br+GJamQG3XkmupSu5sfpGijcxZC0o/YiOQw4ORxIPU6XadMbo19K Q3/7bItgKDgZNJvVCat5hyGvWSLgWfaRR81TDqg8q+R0V3tRkMyhcZ9qgiy9nF0OBTI/ JE+vd6+2wZTCKagGYeWEEJvME3vH6D8rr8deoZmVYH6hCUXdhR8oR2mkaJW5L6pLnCjG Tkgg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b5-v6si17344512pgd.54.2018.09.03.02.01.56; Mon, 03 Sep 2018 02:02:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727465AbeICNT1 (ORCPT + 99 others); Mon, 3 Sep 2018 09:19:27 -0400 Received: from mx2.suse.de ([195.135.220.15]:51416 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727093AbeICNT1 (ORCPT ); Mon, 3 Sep 2018 09:19:27 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id E09B5AEF7; Mon, 3 Sep 2018 09:00:13 +0000 (UTC) Date: Mon, 3 Sep 2018 11:00:11 +0200 From: Michal Hocko To: Pasha Tatashin Cc: "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "kirill.shutemov@linux.intel.com" , "linux-mm@kvack.org" , "jglisse@redhat.com" , "dan.j.williams@intel.com" , "jslaby@suse.cz" Subject: Re: [PATCH] mm: Disable deferred struct page for 32-bit arches Message-ID: <20180903090011.GB14951@dhcp22.suse.cz> References: <20180831150506.31246-1-pavel.tatashin@microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180831150506.31246-1-pavel.tatashin@microsoft.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 31-08-18 15:05:09, Pavel Tatashin wrote: > Deferred struct page init is needed only on systems with large amount of > physical memory to improve boot performance. 32-bit systems do not benefit > from this feature. > > Jiri reported a problem where deferred struct pages do not work well with > x86-32: > > [ 0.035162] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > [ 0.035725] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > [ 0.036269] Initializing CPU#0 > [ 0.036513] Initializing HighMem for node 0 (00036ffe:0007ffe0) > [ 0.038459] page:f6780000 is uninitialized and poisoned > [ 0.038460] raw: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff > [ 0.039509] page dumped because: VM_BUG_ON_PAGE(1 && PageCompound(page)) > [ 0.040038] ------------[ cut here ]------------ > [ 0.040399] kernel BUG at include/linux/page-flags.h:293! > [ 0.040823] invalid opcode: 0000 [#1] SMP PTI > [ 0.041166] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc1_pt_jiri #9 > [ 0.041694] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014 > [ 0.042496] EIP: free_highmem_page+0x64/0x80 > [ 0.042839] Code: 13 46 d8 c1 e8 18 5d 83 e0 03 8d 04 c0 c1 e0 06 ff 80 ec 5f 44 d8 c3 8d b4 26 00 00 00 00 ba 08 65 28 d8 89 d8 e8 fc 71 02 00 <0f> 0b 8d 76 00 8d bc 27 00 00 00 00 ba d0 b1 26 d8 89 d8 e8 e4 71 > [ 0.044338] EAX: 0000003c EBX: f6780000 ECX: 00000000 EDX: d856cbe8 > [ 0.044868] ESI: 0007ffe0 EDI: d838df20 EBP: d838df00 ESP: d838defc > [ 0.045372] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210086 > [ 0.045913] CR0: 80050033 CR2: 00000000 CR3: 18556000 CR4: 00040690 > [ 0.046413] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 > [ 0.046913] DR6: fffe0ff0 DR7: 00000400 > [ 0.047220] Call Trace: > [ 0.047419] add_highpages_with_active_regions+0xbd/0x10d > [ 0.047854] set_highmem_pages_init+0x5b/0x71 > [ 0.048202] mem_init+0x2b/0x1e8 > [ 0.048460] start_kernel+0x1d2/0x425 > [ 0.048757] i386_start_kernel+0x93/0x97 > [ 0.049073] startup_32_smp+0x164/0x168 > [ 0.049379] Modules linked in: > [ 0.049626] ---[ end trace 337949378db0abbb ]--- > > We free highmem pages before their struct pages are initialized: > > mem_init() > set_highmem_pages_init() > add_highpages_with_active_regions() > free_highmem_page() > .. Access uninitialized struct page here.. > > Because there is no reason to have this feature on 32-bit systems, just > disable it. > > Fixes: 2e3ca40f03bb ("mm: relax deferred struct page requirements") > Cc: stable@vger.kernel.org > > Reported-by: Jiri Slaby > Signed-off-by: Pavel Tatashin I would swear something like this has been already proposed. Anyway, looks good to me. I guess we could fix 32b but there is no good reason to complicate 32b code just to allow for an optimization which is not worth it. Acked-by: Michal Hocko > --- > mm/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/Kconfig b/mm/Kconfig > index a550635ea5c3..de64ea658716 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -637,6 +637,7 @@ config DEFERRED_STRUCT_PAGE_INIT > depends on NO_BOOTMEM > depends on SPARSEMEM > depends on !NEED_PER_CPU_KM > + depends on 64BIT > help > Ordinarily all struct pages are initialised during early boot in a > single thread. On very large machines this can take a considerable > -- > 2.18.0 -- Michal Hocko SUSE Labs