From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B97B21A6825 for ; Tue, 12 May 2026 01:15:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778548558; cv=none; b=W4oLTKQSvKUm0ziCVhB2LbSHoxxkqMZXq6GWmSJHyirGUzx+EwjV1SjigGUZwakvc+KujUcf6JjC2kDfalhWkHThH5rfK36sxxhwXFuJnhspQyWdST77k4pAARZtvwMZHQN2RM1a3Ensf1MdH2WjTsGl/kYt/GO7/bKUG1hM5c8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778548558; c=relaxed/simple; bh=2MqZ8BWj0SLzAiBN9tYqJyeHtoGXEVC5wJgzzI/Gwkw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=eVrxg+aTn+ekOvv14U50Dqzdiphh0Ehru8Ma/saJJb0rQvvot1ziLizRo1MTjuDOKnB+/UiYqkTyG+p2XHI7Dohgzs5WgT3Nm8TmrWgd0De1TVULzMULBeK1hbve/nj5/YGEDEP36acJDyqah6KtJLms4bQescIJ8IQlGmTgl+M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=NjZNIQ1w; arc=none smtp.client-ip=115.124.30.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="NjZNIQ1w" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1778548553; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=SdIkXC2hhhsU6vb6OXp8W9bqyYpOKZS9DgZSp5+mh0E=; b=NjZNIQ1wGi/aUdsFQXqwFDHGrO3nF5PJ00T0W+LCm8zhvA88jt/6Zc4tLiGQQZ/C+IZsVJMY/VYuj0MLbqHWeFc6WGGFzs8bpd7BoC0s2JvRKDn62mERAp5HheVQ1aUfZ6QdoTEumSZ1yt4XgJSepFVChkMAeR50KBowt6Ex1t4= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R781e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045133197;MF=cp0613@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0X2obJHU_1778548545; Received: from DESKTOP-S9E58SO.localdomain(mailfrom:cp0613@linux.alibaba.com fp:SMTPD_---0X2obJHU_1778548545 cluster:ay36) by smtp.aliyun-inc.com; Tue, 12 May 2026 09:15:52 +0800 From: Chen Pei To: guoren@kernel.org Cc: alex@ghiti.fr, alexghiti@rivosinc.com, bjorn@rivosinc.com, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, palmer@dabbelt.com, paul.walmsley@sifive.com, Chen Pei Subject: Re: [PATCH V2] riscv: mm: Fixup no5lvl failure when vaddr is invalid Date: Tue, 12 May 2026 09:15:32 +0800 Message-ID: <20260512011542.2329-1-cp0613@linux.alibaba.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260125055212.433163-1-guoren@kernel.org> References: <20260125055212.433163-1-guoren@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=y Content-Transfer-Encoding: 8bit On Sun, 25 Jan 2026 00:52:12 -0500, guoren@kernel.org wrote: > Unlike no4lvl, no5lvl still continues detect satp, which > requires va=pa mapping. When pa=0x800000000000, no5lvl > would fail in Sv48 mode due to an illegal VA value of > 0x800000000000. > > So, prevent detecting the satp flow for no5lvl, when > vaddr is invalid. Add the is_vaddr_valid() function for > checking. > > Fixes: 26e7aacb83df ("riscv: Allow to downgrade paging mode from the command line") > Cc: Alexandre Ghiti > Cc: Björn Töpel > Signed-off-by: Guo Ren (Alibaba DAMO Academy) > --- > Changelog: > > v2: > - Use is_vaddr_valid() instead of simple return. > - Don't change the original no5lvl code logic. > > v1: > https://lore.kernel.org/linux-riscv/20260118145441.291302-1-guoren@kernel.org/ > --- > arch/riscv/mm/init.c | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > index addb8a9305be..bfea9f73e703 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -852,6 +852,27 @@ static void __init set_mmap_rnd_bits_max(void) > mmap_rnd_bits_max = MMAP_VA_BITS - PAGE_SHIFT - 3; > } > > +static bool __init is_vaddr_valid(unsigned long va) > +{ > + unsigned long up = 0; > + > + switch (satp_mode) { > + case SATP_MODE_39: > + up = 1UL << 38; > + break; > + case SATP_MODE_48: > + up = 1UL << 47; > + break; > + case SATP_MODE_57: > + up = 1UL << 56; > + break; > + default: > + return false; > + } > + > + return (va < up) || (va >= (ULONG_MAX - up + 1)); > +} > + > /* > * There is a simple way to determine if 4-level is supported by the > * underlying hardware: establish 1:1 mapping in 4-level page table mode > @@ -893,6 +914,9 @@ static __init void set_satp_mode(uintptr_t dtb_pa) > set_satp_mode_pmd + PMD_SIZE, > PMD_SIZE, PAGE_KERNEL_EXEC); > retry: > + if (!is_vaddr_valid(set_satp_mode_pmd)) > + goto out; > + > create_pgd_mapping(early_pg_dir, > set_satp_mode_pmd, > pgtable_l5_enabled ? > @@ -915,6 +939,7 @@ static __init void set_satp_mode(uintptr_t dtb_pa) > disable_pgtable_l4(); > } > > +out: > memset(early_pg_dir, 0, PAGE_SIZE); > memset(early_p4d, 0, PAGE_SIZE); > memset(early_pud, 0, PAGE_SIZE); Tested-by: Chen Pei Thanks, Pei