Infinite loop in the implementation for arm64 mmu discard_table

[Dat-NguyenDuy]

Hello,

Currently, there is an infinite loop in the implementation for arm64 mmu discard_table: https://github.com/zephyrproject-rtos/zephyr/blob/main/arch/arm64/core/mmu.c#L440. Look like this is an intended behavior under normal circumstances
as mentioned in #46617.

I'm having a big trouble with this infinite loop. Indeed, i'm running Zephyr on cortex-A53 on a SoC that haven't been upstreamed,
there is one of my case reach to this (discard_table) function and never get out (because of the infinite loop) until an exception is raised.

The issue can be reproduced with qemu_cortex_a53 board:

• Zephyr version: a2541d6 (https://github.com/zephyrproject-rtos/zephyr/commits/a2541d6c82437b02fb26db5e8dd1928e5fd0b1d5)

• source code in main.c:

#include <zephyr/sys/mem_manage.h>
#include <zephyr/sys/printk.h>
#include <string.h>

#include <zephyr/app_memory/app_memdomain.h>

__aligned(CONFIG_MMU_PAGE_SIZE)  uint8_t user_buf[4096];

#define USER_STACKSIZE	2048

struct k_thread user_thread;
K_THREAD_STACK_DEFINE(user_stack, USER_STACKSIZE);

struct k_mem_partition test_partition = {
	.start = (uintptr_t)user_buf,
	.size  = 4096,
	.attr  = K_MEM_PARTITION_P_RW_U_RW
};

static void user_function(void *p1, void *p2, void *p3)
{
	__ASSERT(k_is_user_context(), "User mode execution was expected");

	memset(user_buf, 0xFF, sizeof(user_buf));
}

void main(void)
{
	uint8_t *virt_addr;

	k_mem_domain_add_partition(&k_mem_domain_default, &test_partition);

	z_phys_map(&virt_addr, 0x40200000, 0x1FF000, 0x8);
        z_phys_map(&virt_addr, 0x400E0000, 0x1000, 0x8);
        z_phys_unmap(virt_addr, 0x1000);

        /* Issue happens at here */
	z_phys_map(&virt_addr, 0x40400000, 0x200000, 0x8);

	printk("Map and unmap successful\n");

	k_thread_create(&user_thread, user_stack, USER_STACKSIZE,
			user_function, NULL, NULL, NULL,
			-1, K_USER, K_MSEC(0));
}

• content in prj.conf (same as in samples/userspace/hello_world_user):

CONFIG_USERSPACE=y
CONFIG_APPLICATION_DEFINED_SYSCALL=y
CONFIG_ASSERT=y
CONFIG_LOG=y
CONFIG_LOG_MODE_MINIMAL=y
CONFIG_MAIN_STACK_SIZE=2560

• the output log in qemu_cortex_a53 (i modified arch/arm64/core/mmu.c to printing "reach to discard_table" when this function is reached):

~/zephyr$ west build -t run
-- west build: running target run
[0/1] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: cortex-a53
*** Booting Zephyr OS build zephyr-v3.3.0-755-g8eea8cea5881 ***
reach to discard_table
ASSERTION FAIL [xlat_use_count[i] > 0] @ WEST_TOPDIR/zephyr/arch/arm64/core/mmu.c:75
        usage count underflow
E: ELR_ELn: 0x0000000040003a60
E: ESR_ELn: 0x0000000056000002
E:   EC:  0x15 (Unknown)
E:   IL:  0x1
E:   ISS: 0x2
E: TPIDRRO: 0x0100000040027a70
E: x0:  0x0000000040027a70  x1:  0x000000000000004b
E: x2:  0x0000000040012d71  x3:  0x0000000040075bd0
E: x4:  0x0000000000000000  x5:  0x0000000040075d50
E: x6:  0x0000000000000007  x7:  0x0000000000000000
E: x8:  0x0000000000000004  x9:  0x00000000ffffffff
E: x10: 0x0000000000000000  x11: 0x0000000000000000
E: x12: 0x0000000000000000  x13: 0x0000000000000000
E: x14: 0x0000000000000000  x15: 0x0000000000000000
E: x16: 0x0000000040006e24  x17: 0x0000000000000000
E: x18: 0x0000000000000000  lr:  0x0000000040004bfc
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
E: Current thread: 0x400276c0 (unknown)
E: Halting system

Below are two things that i'm concerning about:

1. If the infinite loop in discard_table isn't intended behavior, this function must be updated to break out the loop after the whole table (512 entries) is discarded. Mostly add the i < Ln_XLAT_NUM_ENTRIES will work

2. If the infinite loop in discard_table is an intended behavior and this function should not be reached under normal circumstances. I think there would be a bug somewhere in current implementation for arm64 mmu.

Please let me know if more information need to be provided, thank you!

[manuargue]

Tagging arm64 arch maintainer @carlocaione

[carlocaione]

@Dat-NguyenDuy what are you trying to do? That source code looks really weird. Why are you trying to map twice the same phys with hardcoded values?

[Dat-NguyenDuy]

Hi @carlocaione, sorry for my bad, i updated the source to map difference physical address. Btw the issue is not related to the physical addresses are different or not.

[carlocaione]

@npitre can you take a look at this?

[npitre]

Somebody must have been on drugs _twice_ for sure. Fixed in PR #55500.

[Dat-NguyenDuy]

ok, thanks for confirmation and the quick fixing