Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp534972imu; Fri, 9 Nov 2018 01:43:23 -0800 (PST) X-Google-Smtp-Source: AJdET5fuGB/iqYVSS2HLhG3qd/2yGLhxgqbUBR925GqJBh1QHYFrhD6HsWIVrc3mCRSqpeJAaSqA X-Received: by 2002:a17:902:a988:: with SMTP id bh8-v6mr358885plb.163.1541756603282; Fri, 09 Nov 2018 01:43:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541756603; cv=none; d=google.com; s=arc-20160816; b=mZno3FSEn2As1oHgUWtcE6jaZMoMpX92orr8ue4y/rgsuGk9oyWy5kJZOlfuk0vceI qXxO6afdnGpaLipqTsWvyTl0TtA2AiEmhVGRs3BXA+5MwUtErL1PsGHTknl8yKa4jXYv DtQLgGO3GH4kQp6+2PyNDN6UUc61PqT4fwvBdHsPeOoU8u3bdSGyOSGMILJdDR9hLEE3 +8qKBOYDbHiAsIo1MEyVWbduqrEzskdWfOHD/23eNdXNd/UJ0CchHYlIqjHDANEWLb56 qR+HmnNB0WVoKrI+NDClYHkOVmV3kdgtKSKT/BM2FGYl8Gbw4VcWqpswEMFqHRc2iiPA odDw== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=A6eqavRucPpNiNVGrZXxiy5k1Ebw6K0WVU9e3hoh2+g=; b=kYLpquwnbY2HruzKqGp3m0W1M8K2DgXHcXU8Gl/kU44Ifxz7Z474DohFQQbb2QGMnm ne2JQZGGAOgVD62V6lrT5Clf8DzqvghSk7awAeMEP6p4RfMQtEAU8kdam/Wn58nR/wWH Y0zusrp1zNL0wyrFgID3gsZ8ln8loiK17ZOA7U2l68oKzH449+cwd+3eTKq7s/lgleEl TWEqa61rrenATrtCSaeSc/6hspn+YxoaaTy+gv8hkmi2qdEvR1VjhKdMEpnzuq0H3ETu Zo2H01Mc3e9g1+QkuJhFXXXCmMzkpWld3eudzctLcodjTjzK8b3oIch+5H/d4NTSDWtK ypGA== 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 u64si6459051pgd.262.2018.11.09.01.43.07; Fri, 09 Nov 2018 01:43:23 -0800 (PST) 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 S1727758AbeKITWY (ORCPT + 99 others); Fri, 9 Nov 2018 14:22:24 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:29985 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727560AbeKITWY (ORCPT ); Fri, 9 Nov 2018 14:22:24 -0500 Received: from fsav106.sakura.ne.jp (fsav106.sakura.ne.jp [27.133.134.233]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id wA99fulv005070; Fri, 9 Nov 2018 18:41:56 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav106.sakura.ne.jp (F-Secure/fsigk_smtp/530/fsav106.sakura.ne.jp); Fri, 09 Nov 2018 18:41:56 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/530/fsav106.sakura.ne.jp) Received: from [192.168.1.8] (softbank060157065137.bbtec.net [60.157.65.137]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id wA99fqCP005009 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Fri, 9 Nov 2018 18:41:56 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Subject: Re: UBSAN: Undefined behaviour in mm/page_alloc.c To: Michal Hocko , Kyungtae Kim Cc: akpm@linux-foundation.org, pavel.tatashin@microsoft.com, vbabka@suse.cz, osalvador@suse.de, rppt@linux.vnet.ibm.com, aaron.lu@intel.com, iamjoonsoo.kim@lge.com, alexander.h.duyck@linux.intel.com, mgorman@techsingularity.net, lifeasageek@gmail.com, threeearcat@gmail.com, syzkaller@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Konstantin Khlebnikov References: <20181109084353.GA5321@dhcp22.suse.cz> From: Tetsuo Handa Message-ID: Date: Fri, 9 Nov 2018 18:41:53 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20181109084353.GA5321@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018/11/09 17:43, Michal Hocko wrote: > @@ -4364,6 +4353,17 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid, > gfp_t alloc_mask; /* The gfp_t that was actually used for allocation */ > struct alloc_context ac = { }; > > + /* > + * In the slowpath, we sanity check order to avoid ever trying to Please keep the comment up to dated. I don't like that comments in OOM code is outdated. > + * reclaim >= MAX_ORDER areas which will never succeed. Callers may > + * be using allocators in order of preference for an area that is > + * too large. > + */ > + if (order >= MAX_ORDER) { Also, why not to add BUG_ON(gfp_mask & __GFP_NOFAIL); here? > + WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)); > + return NULL; > + } > + > gfp_mask &= gfp_allowed_mask; > alloc_mask = gfp_mask; > if (!prepare_alloc_pages(gfp_mask, order, preferred_nid, nodemask, &ac, &alloc_mask, &alloc_flags)) >