Received: by 10.192.165.148 with SMTP id m20csp4325779imm; Mon, 30 Apr 2018 16:28:35 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpCEoLjpeWdKvPHOPeZp43Gbd0HJWmHRFTvTEoE5u8LGAfenac+UXkxZwkB1Cs7QRNxEzmd X-Received: by 2002:a17:902:274a:: with SMTP id j10-v6mr14495653plg.393.1525130915911; Mon, 30 Apr 2018 16:28:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525130915; cv=none; d=google.com; s=arc-20160816; b=n9E7zMTrKncGxBdqUeQFNFqGdH3b2rxIrgbIsaDP3ddTXOjzqF1oFx6PiJS9njB+Ve jX3UBKitmLT7d05qol/xyFn8+Rvobe9QCS+CmgaYfArpV54QZsPhA/fJ3aZz2CNUu7qw 0ezX0CasugoarC0vqdWUSa3pa26xSEXBm1csOCIVHl32MXDR0XO8QLZQnGXi8EgG2+yD 3EJH4sqFHDch55mE2ACn3Ox6p52qnQI3/6oHTy7wzIjUQcoP6/NZ7q9OwQaNg8QixWM8 8+HcgZy2sPGcdu2nFUJQM8IkkJAIE5M0LbDHBy7Rc44xFjiY6kCQULWrKUN4eqrJhUz0 fV2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=1RiRh7CXoMRzuOKu782cG2RCqhMBUWruz5wWxglhngI=; b=j1VG0lhQvgsDQNr3uSqzPD5DPLRwuUKJtkqV5PHdtJLejAB4KZmGvUB3uql8ARCKic IekXyU4BgwXJ8EXkMZFpFKat0g6PFg6QKkjPbELcWZVw5/jngypGTNWwu4IAn9MOSxW0 /kN9tvUzF0Mm2ncA12fqW6qJANMFJWanOawWTj0j6OSMXpqQJxczKl805NRIYA6EOIKE JSmn48ih8y/E9wy6EraJ7vvdP0EeU+f5yDKySkiWN65dOofLvCWsRHhzyO3/5kIjF12o KJ8sCO9iZwdRhubyBUNGRxouprQIliqAdZO+QFJ35ntwiCu10ZaD4bf5XtTWY/iMTBrR fkFw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t144-v6si6877583pgb.94.2018.04.30.16.28.21; Mon, 30 Apr 2018 16:28:35 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755442AbeD3X1B (ORCPT + 99 others); Mon, 30 Apr 2018 19:27:01 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:43718 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753594AbeD3X1A (ORCPT ); Mon, 30 Apr 2018 19:27:00 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.71]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id B84F3825; Mon, 30 Apr 2018 23:26:59 +0000 (UTC) Date: Mon, 30 Apr 2018 16:26:58 -0700 From: Andrew Morton To: Pavel Tatashin Cc: steven.sistare@oracle.com, daniel.m.jordan@oracle.com, linux-kernel@vger.kernel.org, tglx@linutronix.de, mhocko@suse.com, linux-mm@kvack.org, mgorman@techsingularity.net, mingo@kernel.org, peterz@infradead.org, rostedt@goodmis.org, fengguang.wu@intel.com, dennisszhou@gmail.com Subject: Re: [PATCH v2] mm: access to uninitialized struct page Message-Id: <20180430162658.598dd5dcdd0c67e36953281c@linux-foundation.org> In-Reply-To: <20180426202619.2768-1-pasha.tatashin@oracle.com> References: <20180426202619.2768-1-pasha.tatashin@oracle.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 26 Apr 2018 16:26:19 -0400 Pavel Tatashin wrote: > The following two bugs were reported by Fengguang Wu: > > kernel reboot-without-warning in early-boot stage, last printk: > early console in setup code > > http://lkml.kernel.org/r/20180418135300.inazvpxjxowogyge@wfg-t540p.sh.intel.com > > ... > > --- a/init/main.c > +++ b/init/main.c > @@ -585,8 +585,8 @@ asmlinkage __visible void __init start_kernel(void) > setup_log_buf(0); > vfs_caches_init_early(); > sort_main_extable(); > - trap_init(); > mm_init(); > + trap_init(); > > ftrace_init(); Gulp. Let's hope that nothing in mm_init() requires that trap_init() has been run. What happens if something goes wrong during mm_init() and the architecture attempts to raise a software exception, hits a bus error, div-by-zero, etc, etc? Might there be hard-to-discover dependencies in such a case?