Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2004744imm; Thu, 23 Aug 2018 12:27:16 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwtrhqL4fdOdGZhWDi5PyVh7I9ndVPZPvR7ev6KDUpGVbJVqZ6RlQcHWPPuCZXGA3i6iuq8 X-Received: by 2002:a17:902:a716:: with SMTP id w22-v6mr59884566plq.334.1535052436246; Thu, 23 Aug 2018 12:27:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535052436; cv=none; d=google.com; s=arc-20160816; b=tmKe63RD4pgq0hloVafEn5jp2k1lnSN/qzLzh3eq5D7019Gayc1q+VQuREVhYyINEL ObsewxAIaQAZ0cxSW+awcXNb9IHSGUlXfkbFIMSHB45t+OXaFKUXqidLacw7IR1lrxSq ZheVH/4rMt1pFGvLchHsTR/b9pEPVc281x5CBqp63hlWrsK/aXV/12HssDWkmAqsHqoY diBDHxRenPjxLv7XBQU3bECyO8kFO6YwYYi2RHT+n/d0i/dLtE3hicqlTPMPuqFOOEbN IdTqBJ2gBBahR82y1fIY1CjRgj04j4kzNGbJp9VxEQs6AjIXVlz5MU2MFEIhJhvT1UiO xCMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=eGRAaiReRQqvY/PwQbQScnuCBovUsPZDslZzbaKLUNc=; b=G8owO47wq7NkwSongfJN0BtO9Tnhol0PtIQ33X0SZMzVVvbDwr3EPKHpu7DXs7OXax uVNvdA9t5duTaY6e8JVRWh8SDuSyxiY6dZzT1zdl+pY7dATh4LYWodXPGVFH5jg4mMfe CLA3ZIbXiFH5F59ryMtbX8d+IZf2QeRAqGR8FFDTSa4wEBF02EdYDUf+A7DlpP8Go8dL 9v4zoQp8JBNwlKcq6CM1Fpl9YvDpl+C94mYCwNfyRFbVHpU5ZaTKc7aXoGyfYhOk0vWo bwTZyWykXFwKgfijkubXbAx5FCmmksVq+dXWWcG38MrCI8hxV8pDBQal4ke1adJk11S8 wqmA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p6-v6si5627029pfh.266.2018.08.23.12.27.00; Thu, 23 Aug 2018 12:27:16 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726511AbeHWW5A (ORCPT + 99 others); Thu, 23 Aug 2018 18:57:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:59496 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726083AbeHWW47 (ORCPT ); Thu, 23 Aug 2018 18:56:59 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 60B1FAEC0; Thu, 23 Aug 2018 19:25:50 +0000 (UTC) Date: Thu, 23 Aug 2018 21:25:47 +0200 From: Michal Hocko To: Andi Kleen Cc: Vlastimil Babka , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds , Dave Hansen , stable@vger.kernel.org Subject: Re: [PATCH] x86/speculation/l1tf: suggest what to do on systems with too much RAM Message-ID: <20180823192547.GS29735@dhcp22.suse.cz> References: <20180823134418.17008-1-vbabka@suse.cz> <20180823142812.7363-1-vbabka@suse.cz> <20180823154648.GD12066@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180823154648.GD12066@tassilo.jf.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 23-08-18 08:46:48, Andi Kleen wrote: > On Thu, Aug 23, 2018 at 04:28:12PM +0200, Vlastimil Babka wrote: > > Two users have reported [1] that they have an "extremely unlikely" system > > with more than MAX_PA/2 memory and L1TF mitigation is not effective. Let's > > make the warning more helpful by suggesting the proper mem=X kernel boot param, > > a rough calculation of how much RAM can be lost (not precise if there's holes > > between MAX_PA/2 and max_pfn in the e820 map) and a link to the L1TF document > > to help decide if the mitigation is worth the unusable RAM. > > I'm not sure anyone would really do that. After all you probably prefer > your memory. And if it's really a non ECC client part they are are > already used to to live very dangerously because their undetected RAM bit error > rate will be significant. L1TF is probably one of your smaller problems > in this case... There are people who care about L1TF mitigations. I am not going to question their motivation. In any case a hint how to make the mitigation active again sounds more useful than something that sounds as scary as "you are vulnerable". -- Michal Hocko SUSE Labs