Received: by 10.192.165.148 with SMTP id m20csp5063178imm; Tue, 24 Apr 2018 13:02:53 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+LdD9ZBsJF0eILbXHl+BvG4i+44qdsJ5/zNZX4adJMlv/C/d4qF1PRW05p1c4ZKBjYnFmE X-Received: by 10.99.153.17 with SMTP id d17mr20071549pge.106.1524600173006; Tue, 24 Apr 2018 13:02:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524600172; cv=none; d=google.com; s=arc-20160816; b=T/u+0ysowbYfHGDDrmn0iIJD9JNgLCtDkJcZBGLL3+XcCYcu9l5u44iMXhenNeGhJz d1ikr+b5LqUfDGOfl1RhwGRCPITarYdt8fvC9cdTU6kw88hICRURpeosjkH1H32icxxn tbdRudFkpqGEEdY8hTyvavpry2rMv2TSPHRTOVtwxu9SOEAvQd+PC6x/5MWl+QzYddtU HR9rvQ4LwFEd1gA7QUJgn+5PX0sjp/HPSa4BG5UaoMuk3YgEH438+GSf2rWg0Do53BVK hJkJ7nfe1zjGNlnIvA6687qDljjepKi+sR5tLTter46L4KYI5cjyYWnt9nLjRtNEuO+3 UsoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=72QDjEOfnHKXRbPx1ZJ+M0VQ42libQjgNu7o82fHn0w=; b=LBkhLIcRHDnrkUD/r7gKXvA3JBQ6KC8n088iTwq1u+h4CkbGbXLp4rtrL6XwHyvW02 3WFsWDTNxZxkwsLePLbEeBW0IR++SnDQnqIQG/qScQlNc4ql4AdZuqx+tbgNNJW+B5+E cjP8h6RyRQJ7Qu78t6q2KA1RghP0zxjVCKTxpAqj1KtB1zZtjaH1kR0B7l6X/rIkVKhQ 1VDHRX55HPpObwRWWkay0DndZZEf+Gs/+w9E6uPu73JJhSCIKg16xlDQrjVPcsRF5yMO TVp4rv8wOGH6WWf5SQJII5rOMLDmrM8KKnKCtHhh6ZZrzQ1MVmfH4FZvMXH2nveIg94N K7DQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=g3Q8i/Rf; 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=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r24si11836283pgu.402.2018.04.24.13.02.38; Tue, 24 Apr 2018 13:02:52 -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; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=g3Q8i/Rf; 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=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750902AbeDXUBD (ORCPT + 99 others); Tue, 24 Apr 2018 16:01:03 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:55064 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750739AbeDXUBB (ORCPT ); Tue, 24 Apr 2018 16:01:01 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3OJuVT8107491 for ; Tue, 24 Apr 2018 20:01:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : in-reply-to : references : from : date : message-id : subject : to : cc : content-type; s=corp-2017-10-26; bh=72QDjEOfnHKXRbPx1ZJ+M0VQ42libQjgNu7o82fHn0w=; b=g3Q8i/RfoQR4SyPl+7a7PtD2xm3knDofC0LfD33FPrEP1P/TWp6ntZcyRvn6wy1yLgfy wmAvHG1Bg4DeWZebHtIomU67gShFB5my/oXUykRYRxM58HdHNPQOs9Kg8NNDAwVrmM3e bbl7u/lKslCI7MdK+AidPM0Vk9KSzO71vPKSLAccd6tHBTWNxDxkm/AzwoneWuqE9ZXz xFqJBab6zyVYNXUACPw+81WeVXyslAKUsg2ckw0Ecdq7yXlgS4Bw9OVsCal2v8OwXH7p hDxsoqzveh8cWPGb0BIvI9cMZGIWSyOMKlby20jNHFehLjCojJL6kRAyTeZL1y9OnAYh 4Q== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2hfwy9ksg6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 24 Apr 2018 20:01:01 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w3OK0xkU015705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 24 Apr 2018 20:00:59 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w3OK0xRk030529 for ; Tue, 24 Apr 2018 20:00:59 GMT Received: from mail-ot0-f170.google.com (/74.125.82.170) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Apr 2018 13:00:59 -0700 Received: by mail-ot0-f170.google.com with SMTP id y10-v6so9723855otg.10 for ; Tue, 24 Apr 2018 13:00:59 -0700 (PDT) X-Gm-Message-State: ALQs6tCQqL4SQPm7jJVP4cGdj6lK8qLGaD83U9AmBK4iIatcJJArpfJL qpnzgavkiQoI/CNck1hxK+N0Cu6pQRaCKkl8C/Q= X-Received: by 2002:a9d:4318:: with SMTP id s24-v6mr14114354ote.345.1524600051655; Tue, 24 Apr 2018 13:00:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2322:0:0:0:0:0 with HTTP; Tue, 24 Apr 2018 13:00:11 -0700 (PDT) In-Reply-To: <20180420152922.21f43e52@gandalf.local.home> References: <20180420191042.23452-1-pasha.tatashin@oracle.com> <20180420152922.21f43e52@gandalf.local.home> From: Pavel Tatashin Date: Tue, 24 Apr 2018 16:00:11 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [v1] mm: access to uninitialized struct page To: Steven Rostedt Cc: Steven Sistare , Daniel Jordan , Andrew Morton , LKML , tglx@linutronix.de, Michal Hocko , Linux Memory Management List , mgorman@techsingularity.net, mingo@kernel.org, peterz@infradead.org, Fengguang Wu , Dennis Zhou Content-Type: text/plain; charset="UTF-8" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8873 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804240189 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Steven, Thank you for your review: >> https://lkml.org/lkml/2018/4/18/797 > > #2, Do not use "lkml.org" it is a very unreliable source. > OK > I'm fine with this change, but what happens if mm_init() traps? > > But that is probably not a case we really care about, as it is in the > very early boot stage. Yes, the assumption is that we do not trap in mm_init(), which I think is the case because of early boot, and also I did not see this happen during testing. > >> >> ftrace_init(); >> > > One thing I could add is to move ftrace_init() before trap_init(). But > that may require some work, because it may still depend on trap_init() > as well. But making ftrace_init() not depend on trap_init() is easier > than making it not depend on ftrace_init(). Although it may require > more arch updates. > > I'm not saying that you should move it, it's something that can be > added later after this change is implemented. This makes, sense, but should be done outside of this bug fix. > > Reviewed-by: Steven Rostedt (VMware) > Thank you. I will send out an updated patch. Pavel