Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp85543pxa; Tue, 11 Aug 2020 18:09:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx7ZU2qDWg7lP7D4lIoGev/wew5DOC3pbOSIhWrWP8dkYT1Us54vZrEPyXkZUSHKDi3iLjz X-Received: by 2002:a05:6402:3199:: with SMTP id di25mr29162964edb.315.1597194596729; Tue, 11 Aug 2020 18:09:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597194596; cv=none; d=google.com; s=arc-20160816; b=s6y9GoyzxQyGOYp/nrsE2Ia1OEIPZoG8Gy6MnsZcfH5ZS5+KPCPXfZ4CxdpsHF3LDx XXnZVVG3dlzuJNWWewaRnrnqwzQDPnqRh6prwM7qTz9HpnMCruHo2OiCmIzzhhO1Sw5I p5HY4aG+mpESpashddj420/hT4ZzBJHsw3HKOwneX32FrNj43ulHHfAe7Oazf+VWjqYP Xy/JN5UE6WAvC2E/vMcVfgqYFyh/XMWqHHC0QyYaHWNLuSViWZDKrbuD40QHE71XNyVe /uxSV9XxZmS7Agqw+IQt4YL2PZjOJN4T3yb1K3tOxFtPDT3RJUbgZpQETxY6sqiUOLR0 fbJA== 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:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=lO0AF40nWUf8IMy67yLzgZR9TQ6IkcbohMghSbRQAKg=; b=hjxzW3c51i53xPojJa5hjIALQD/9+cGh4cINFa4goekoH/vI2mz92ygjPbdBxfiBA5 xIBkwEpJHmPsiX/ToH4xGFqbETGbGx3DILbeyMq7TduBrYw7jKDfqdr3CjF/9NhpB5QV CMoj9VKGfFHJdKQpaoiv740pJaaYs5dlXN7eZZislvtJny8C+LCd7dskIo6/M/Z1U8wU cU1L5MKu1pcQJJNn4IjXfgOSXzY08Dzc1TsPgQLhpZYlqISjxpMaJX0A98+ewvRSYzRx 1btVU/1Ucsr1FkGNS+cgHy2WkSrWWK9WFH56QmZ11Da7+usSkCgnoHBO3P4hLU6goJtM m6uA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a25si319963edn.30.2020.08.11.18.09.33; Tue, 11 Aug 2020 18:09:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726510AbgHLBIF (ORCPT + 99 others); Tue, 11 Aug 2020 21:08:05 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:39408 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726173AbgHLBIF (ORCPT ); Tue, 11 Aug 2020 21:08:05 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id D453732FD42127E7D3BA; Wed, 12 Aug 2020 09:08:02 +0800 (CST) Received: from [10.174.178.86] (10.174.178.86) by smtp.huawei.com (10.3.19.203) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 12 Aug 2020 09:07:44 +0800 Subject: Re: [PATCH v3 0/8] huge vmalloc mappings To: Jonathan Cameron , Nicholas Piggin CC: , , , , "Catalin Marinas" , Will Deacon , , Thomas Gleixner , Ingo Molnar , Borislav Petkov , , "H. Peter Anvin" References: <20200810022732.1150009-1-npiggin@gmail.com> <20200811173217.0000161e@huawei.com> From: Zefan Li Message-ID: Date: Wed, 12 Aug 2020 09:07:44 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200811173217.0000161e@huawei.com> Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.86] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/8/12 0:32, Jonathan Cameron wrote: > On Mon, 10 Aug 2020 12:27:24 +1000 > Nicholas Piggin wrote: > >> Not tested on x86 or arm64, would appreciate a quick test there so I can >> ask Andrew to put it in -mm. Other option is I can disable huge vmallocs >> for them for the time being. > > Hi Nicholas, > > For arm64 testing with a Kunpeng920. > > I ran a quick sanity test with this series on top of mainline (yes mid merge window > so who knows what state is...). Could I be missing some dependency? > > Without them it boots, with them it doesn't. Any immediate guesses? > I've already reported this bug in v2, and yeah I also tested it on arm64 (not Kunpeng though), so looks like it still hasn't been fixed. ... >> >> Since v2: >> - Rebased on vmalloc cleanups, split series into simpler pieces. >> - Fixed several compile errors and warnings >> - Keep the page array and accounting in small page units because >> struct vm_struct is an interface (this should fix x86 vmap stack debug >> assert). [Thanks Zefan] though the changelog says it's fixed for x86.