From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754513Ab2IIRBt (ORCPT ); Sun, 9 Sep 2012 13:01:49 -0400 Received: from terminus.zytor.com ([198.137.202.10]:49067 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751075Ab2IIRBs (ORCPT ); Sun, 9 Sep 2012 13:01:48 -0400 Message-ID: <504CCB6D.7070005@zytor.com> Date: Sun, 09 Sep 2012 10:01:33 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: Linus Torvalds CC: suresh.b.siddha@intel.com, Sasha Levin , Andrew Morton , dwmw2@infradead.org, "linux-kernel@vger.kernel.org" , linux-mtd@lists.infradead.org, linux-mm , Dave Jones Subject: Re: mtd: kernel BUG at arch/x86/mm/pat.c:279! References: <1340959739.2936.28.camel@lappy> <1347057778.26695.68.camel@sbsiddha-desk.sc.intel.com> <1347062045.26695.82.camel@sbsiddha-desk.sc.intel.com> <1347202600.5876.7.camel@sbsiddha-ivb> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/09/2012 08:31 AM, Linus Torvalds wrote: > On Sun, Sep 9, 2012 at 7:56 AM, Suresh Siddha wrote: >> >> yes but that is not a valid range I think because of the supported >> physical address bit limits of the processor and also the max >> architecture limit of 52 address bits. > > But how could the caller possibly know that? None of those internal > PAT limits are exposed anywhere. > > So doing the BUG_ON() is wrong. I'd suggest changing it to an EINVAL. > > In fact, BUG_ON() is *always* wrong, unless it's a "my internal data > structures are so messed up that I cannot continue". > I suspect the right answer is doing something like: u64 max_phys = 1ULL << boot_cpu_data.x86_phys_bits; if (start >= max_phys || end > max_phys || start >= end) return -EINVAL; ... although max_phys perhaps should be precalculated and stored in struct cpuinfo_x86 instead of being generated de novo. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.