Received: by 10.223.164.221 with SMTP id h29csp1121202wrb; Thu, 26 Oct 2017 12:51:26 -0700 (PDT) X-Google-Smtp-Source: ABhQp+TPdVK+mAHMCo7tYbnRQ6Zo4GDD2U5prDz7b0VQHOVBNkIo72aS/+PJJ9JtjviWt4ygZrrw X-Received: by 10.98.33.90 with SMTP id h87mr6462216pfh.312.1509047486014; Thu, 26 Oct 2017 12:51:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509047485; cv=none; d=google.com; s=arc-20160816; b=YgWrXZ+WHzvSQVipLIF2ap9D1v5CL4Lba7pNDQtjkZrbDYLtvXyuz5vL1pOArb0dom FJRm3YMCVxSvx5Pw5FB5sDxsofqQ2gmQGo3dl1nI02PCHQu6kCqgZt7lopmB9V7gaVMX NKIVN4Kf3O/yq+vDviRRwZ+Gz/bMsyRFPWlHjXIdCSyqiTHMLUbs6jbUgrxAz2U5IuX3 DBcGvKugWenVKgAOsQ4yV3XKOp5NZxrRo+04ptF4TFQXhT/VoD+bsSX78I00jy+6YxgP Px/SvMhQeOG2FJtB1peqb/yS4pbvS9xMhOIQjzip8TQ6KQzGpLwpH+Sh7T1jB7mRsvTC uXjg== 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=KWf+V4eY9g53WNm675wmU2/8Uiw94lE/swRW7xmEqE8=; b=lj1K5zDLimHw1soM1KzWgyVsWFGD50EAxmGIQm+dgELdEQ6VucdGzqPeMBGRFVVRpy 4jPM3Hcp5/j18yd7kSqCRyB2qsil/h9mZP2Lznh6ecKAmt4yz4d+JAp1mAOHoNxAIwkH zVVycSHD4yWBTXQMDHjVxSVyeqIilmk3iySVSg39GQB/6H2ZlPgqKg7Rm0UTlCHv8Y3+ JoYUkpRb0EuDXS46En8cfeORbAouvYwWHubSEFPCaJjdlakQgvrUkFC62sIKqGZlyPQN tUt2NxKrHZP7XJq5tPZS95PvCjxQmK75RfKNQnKIWd3qeJt92UpgZHbZHWUoeusYYez7 GiwQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=DBQq5htQ; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u62si3784833pgc.457.2017.10.26.12.51.09; Thu, 26 Oct 2017 12:51:25 -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=@google.com header.s=20161025 header.b=DBQq5htQ; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932472AbdJZTuo (ORCPT + 99 others); Thu, 26 Oct 2017 15:50:44 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:52262 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932326AbdJZTum (ORCPT ); Thu, 26 Oct 2017 15:50:42 -0400 Received: by mail-wm0-f68.google.com with SMTP id t139so10463123wmt.1 for ; Thu, 26 Oct 2017 12:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KWf+V4eY9g53WNm675wmU2/8Uiw94lE/swRW7xmEqE8=; b=DBQq5htQ5/g0VKKvy7gQpKcFjVOxKPwr7Mxk3tUccxkTyPpTL5owHmmTIDp9aTGsTj 46uGXVCPC9ikDRPdeEiUj+My9WGdnEwQWWY26EUAYumwxsX82XJQfjXQybBo+6JH6ZxQ oMl2yNtjjIY/VXM79p70t/hx1h2q30B5Ex6+HfXegeFeADut+/G4VW+G0X/y1SJ8eT7E aCx8LG3/qPjeFT85Az0YwskVg/dk/XlF3fKfp1YA5zLQ7aNGZ1+jEQ+DkZwCZ8SWdZO/ bw7ltsp6iVvLNnd5ggEoJYFVUovrUIyAZMsmrUdNOGeykCajqVhN+76esjykIJrgcdxn b5xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KWf+V4eY9g53WNm675wmU2/8Uiw94lE/swRW7xmEqE8=; b=EwXwMHQF2JxQrEhy1U3cd6oFaxbkekoP4OizprYPb6qmnzYG916tf+XJZdtzqa9ERR lOFIRQZ83TKaY0SEd8Uo2Nm2D6s3FE/ER4IALGG4AABQ7NMgcj+pv65z/JRCcD/uLh6l eP3GpmY5dzOewp+VXCj0OlSesPAH12OtUORM6KLKt1dx+43iv8qg4XNjHklwQusoJPzq 4p3IoU01v1KJ5TWPw9VLYdFTl3DWwjS6ecRseqyNr0NBNyLhD/fXEekNA1OwWt3SJmrN E8Mjamk1x7b31+hiLpKhnOGv2Brhmky9qsRb+jqNRdnpyD5l/Zh6somNhMtjGONB5rOI RXCg== X-Gm-Message-State: AMCzsaWvYI1RrQDdRICrgZ0z5RwO4VeVJNrw9rMA0qimpvhOHh6Ow9MW tGOD8j921hZrv+9i7n2ibVqcTJm84nB3+uUzBJNblw== X-Received: by 10.28.29.205 with SMTP id d196mr48171wmd.106.1509047441387; Thu, 26 Oct 2017 12:50:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.176.4 with HTTP; Thu, 26 Oct 2017 12:50:40 -0700 (PDT) In-Reply-To: References: <20171024024439.u3ywfgvi67fe4mbg@wfg-t540p.sh.intel.com> <440615a7-6cc0-a607-ce7c-22a34b69e8fe@eikelenboom.it> <1d203c07-0595-a33a-620b-c51eea9721d1@eikelenboom.it> <8721eeac-a644-e815-55e9-5f01956dd22a@eikelenboom.it> <20171026163911.dnovh4zaik5qumtt@gmail.com> <20171026190229.zt743ooxvjsukmis@gmail.com> From: Craig Bergstrom Date: Thu, 26 Oct 2017 13:50:40 -0600 Message-ID: Subject: Re: ce56a86e2a ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses"): kernel BUG at arch/x86/mm/physaddr.c:79! To: Linus Torvalds Cc: Ingo Molnar , Sander Eikelenboom , Boris Ostrovsky , Fengguang Wu , wfg@linux.intel.com, Linux Kernel Mailing List , LKP Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Reverting seems like the right approach at the moment. My apologies for the breakage so late the in the cycle. Post-revert, there remains a bug here wherein you can make the system OOPS if you mmap memory above the 48 bit bus width. Linus/Ingo, is there something in particular that you'd like to see before pulling in a check on the bus width (or some other fix)? Based on Linus' comment, the bus width check smells like something that should cook for a while before pulling into mainline. On Thu, Oct 26, 2017 at 1:29 PM, Linus Torvalds wrote: > On Thu, Oct 26, 2017 at 9:02 PM, Ingo Molnar wrote: >> >> Well, 'mem=2048M' shouldn't really limit device memory, it's supposed to limit >> (trim) 'RAM' and not much else. > > Agreed. You should very much be able to map in IO memory or whatever > above the 2G address even if the high_memory itself might be limited > to 2GB. > > So I think that commit ce56a86e2ade ("x86/mm: Limit mmap() of /dev/mem > to valid physical addresses") is wrong, in that "high_memory" is very > much the wrong thing to test. > > The memory mapping limit might validly be something like > > 1ull << boot_cpu_data.x86_phys_bits > > or similar, but for now I suspect that the right thing to do is to > revert. I'm not convinced that our "x86_phys_bits" value is guaranteed > to be always right, since I think we mainlyjust use it for showing > things, rather than have lots of code that depends on it. > > Ingo? > > Linus From 1582349782608274533@xxx Thu Oct 26 19:32:27 +0000 2017 X-GM-THRID: 1582105239086831553 X-Gmail-Labels: Inbox,Category Forums