Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1768599imu; Thu, 17 Jan 2019 03:01:09 -0800 (PST) X-Google-Smtp-Source: ALg8bN6I/hJnEzaXKkt0vys78IE6owuvLPnn4f5ewGalz7lPM+EmAv0ZSDsgvCf/F/JQJa+PDqzd X-Received: by 2002:a62:1992:: with SMTP id 140mr14486391pfz.33.1547722869210; Thu, 17 Jan 2019 03:01:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547722869; cv=none; d=google.com; s=arc-20160816; b=dq4BqTbcHghMUOF2bSWoFs1bMij+yrJpEB6xiU0cIaQAE8J8OzDdW0QE8X90OaAfCC OEopWrExOSlmSt1RXCjxOqL2/fim4VUnz5sKUwJ5r7b6NdSP1lbMr0Cg8G91jZTE5Srs Xl0ToO085RKLNYaUU3mCsBE/884kfSZqQpU8HWwpN1sN43ru2k+PG4woow88E8+VlbhF lpzyhiNKCsv457/HLCCGRGumQ64VtvV48ndjJJH54j1fHi0PqqY4sLyqcoF1A0n3hI/s 7C21yIzAGYlURvGnssR/35hypOE/Cf9EiL9T6Or/nIAayxADfSjOUqPTO16opFEroec3 T8ww== 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:references:cc:to:subject:from:dkim-signature; bh=j1qBj5EFQPkYjhifaDgiu5IwIYflUbomCpdiIJbHl/U=; b=xRROwYGX+L44byoM1+vtIpQ1Z65SWHhzKwMa7YSD0RMMJYZausKbq3ZsSaDFJtcZ1E f3F3xkBbOATwWH9PwSfj82UiC5REYJ+UQDgcTFmFqMoJvmcrZAYJ/NVir03aQmnd+pzY PsXTQw2hMBo/6luWK8HJ610HOF7du0pnjDRIc033eUIgyniB3Nynl5ww77yhwzDKoiao uCgTPwT1sfeswe2BS64p9fhsxmvKaBvLQqIMbr6VMfQcdPPUxNDNTfL1+3z1Vucc6UaQ 4Zxovj+KU7Z12Dl1Yw7Lryu4pIHYI75XkmRIWaxeqBtUAeOATWKHBin5/4xfJtc9jKm5 ZxlA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@c-s.fr header.s=mail header.b=YAPZ7hYs; 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 d38si1401055pla.207.2019.01.17.03.00.53; Thu, 17 Jan 2019 03:01:09 -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; dkim=pass header.i=@c-s.fr header.s=mail header.b=YAPZ7hYs; 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 S1728687AbfAQK7i (ORCPT + 99 others); Thu, 17 Jan 2019 05:59:38 -0500 Received: from pegase1.c-s.fr ([93.17.236.30]:12233 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728616AbfAQK7f (ORCPT ); Thu, 17 Jan 2019 05:59:35 -0500 Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 43gLgS1XXHz9v2C2; Thu, 17 Jan 2019 11:59:32 +0100 (CET) Authentication-Results: localhost; dkim=pass reason="1024-bit key; insecure key" header.d=c-s.fr header.i=@c-s.fr header.b=YAPZ7hYs; dkim-adsp=pass; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id 46iSN4xSOAEa; Thu, 17 Jan 2019 11:59:32 +0100 (CET) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 43gLgR74jzz9v2By; Thu, 17 Jan 2019 11:59:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c-s.fr; s=mail; t=1547722772; bh=j1qBj5EFQPkYjhifaDgiu5IwIYflUbomCpdiIJbHl/U=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From; b=YAPZ7hYsHmTktDoksvOoxa2yyn51SEVR72WkZZ38CaF1XeW5ZhNiY7OaiolfkllOJ ucbVpENyb82HZnuOu18Rbu2naXfZi5E1CA8lpbl5x5p4HT9YP9tNy61TC2rV8lcqTu D1MhpnINTPGbPCPv30HRLc4UIOPF07KBQs9ZC9iQ= Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 2AAAB8B858; Thu, 17 Jan 2019 11:59:33 +0100 (CET) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id srtPCZbvyH-Y; Thu, 17 Jan 2019 11:59:33 +0100 (CET) Received: from PO15451 (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 1C8918B75B; Thu, 17 Jan 2019 11:59:32 +0100 (CET) From: Christophe Leroy Subject: Re: [RESENDING PATCH] powerpc/wii: properly disable use of BATs when requested. To: =?UTF-8?Q?Jonathan_Neusch=c3=a4fer?= Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, stable@vger.kernel.org References: <7e6748349978f4f177b6a1f3f1c773da98ae3b59.1547570012.git.christophe.leroy@c-s.fr> <20190117010509.GH22334@latitude> Message-ID: <19fd4dd4-ece2-d508-1ed5-5a9ed2aa84fe@c-s.fr> Date: Thu, 17 Jan 2019 11:29:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190117010509.GH22334@latitude> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 17/01/2019 à 02:05, Jonathan Neuschäfer a écrit : > Hi again, > > On Tue, Jan 15, 2019 at 04:43:20PM +0000, Christophe Leroy wrote: >> 'nobats' kernel parameter or some options like CONFIG_DEBUG_PAGEALLOC >> deny the use of BATS for mapping memory. >> >> This patch makes sure that the specific wii RAM mapping function >> takes it into account as well. >> >> Fixes: de32400dd26e ("wii: use both mem1 and mem2 as ram") >> Cc: stable@vger.kernel.org >> Signed-off-by: Christophe Leroy >> --- > [...] >> /* MEM2 64MB@0x10000000 */ >> delta = wii_hole_start + wii_hole_size; >> + if (__map_without_bats) >> + return delta; >> + > > Nothing is visibly broken without this patch, even with > CONFIG_DEBUG_PAGEALLOC (tested on top of v5.0-rc2), but the patch still > looks correct. Obviously, CONFIG_DEBUG_PAGEALLOC cannot work without this patch. The purpose of CONFIG_DEBUG_PAGEALLOC is to unmap unused parts of memory so that any access to them will pagefault. As this function inconditionnaly sets a BAT for the second block of RAM, any access to free area in the upper block will be granted without a fault. I think you can test it by doing a kmalloc() then a kfree(), then try to read in that area (hopefully kmalloc() allocates memory from the top so it should go in the upper block). Maybe there is an LKDTM test for that. > > I'd prefer the 'if' block to be before the whole delta/size calculation, > to make the code slightly more readable because the delta and size > calculations stay in one visual block. It doesn't need to happen after > delta is calculated. Euh ... the function has to return 'delta', so if I put the if block before the calculation of delta, it means we have to calculate delta twice: if (__map_without_bats) return wii_hole_start + wii_hole_size; delta = wii_hole_start + wii_hole_size; My eyes don't really like it, so if we want to keep delta and size calculation together, the 'if' will go after calculation of size. In anycase, this change is only really for fixing stable releases because this function will go away with my other serie. Christophe > > tentatively, > Reviewed-by: Jonathan Neuschäfer > > > Thanks, > Jonathan >