Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NAPOT Fixes #671

Closed
wants to merge 3 commits into from
Closed

NAPOT Fixes #671

wants to merge 3 commits into from

Conversation

bjoto
Copy link

@bjoto bjoto commented Feb 27, 2024

Pull request for series with
subject: NAPOT Fixes
version: 1
url: https://patchwork.kernel.org/project/linux-riscv/list/?series=830425

@bjoto
Copy link
Author

bjoto commented Feb 27, 2024

Upstream branch: d82f322
series: https://patchwork.kernel.org/project/linux-riscv/list/?series=830425
version: 1

@bjoto
Copy link
Author

bjoto commented Feb 28, 2024

Upstream branch: d82f322
series: https://patchwork.kernel.org/project/linux-riscv/list/?series=830425
version: 1

@bjoto
Copy link
Author

bjoto commented Feb 28, 2024

Upstream branch: 3257314
series: https://patchwork.kernel.org/project/linux-riscv/list/?series=830425
version: 1

Alexandre Ghiti added 2 commits February 29, 2024 18:23
This reverts commit ce17347.

We cannot correctly deal with NAPOT mappings in vmalloc/vmap because if
some part of a NAPOT mapping is unmapped, the remaining mapping is not
updated accordingly. For example:

ptr = vmalloc_huge(64 * 1024, GFP_KERNEL);
vunmap_range((unsigned long)(ptr + PAGE_SIZE),
	     (unsigned long)(ptr + 64 * 1024));

leads to the following kernel page table dump:

0xffff8f8000ef0000-0xffff8f8000ef1000    0x00000001033c0000         4K PTE N   ..     ..   D A G . . W R V

Meaning the first entry which was not unmapped still has the N bit set,
which, if accessed first and cached in the TLB, could allow access to the
unmapped range.

That's because the logic to break the NAPOT mapping does not exist and
likely won't. Indeed, to break a NAPOT mapping, we first have to clear
the whole mapping, flush the TLB and then set the new mapping ("break-
before-make" equivalent). That works fine in userspace since we can handle
any pagefault occurring on the remaining mapping but we can't handle a kernel
pagefault on such mapping.

So fix this by reverting the commit that introduced the vmap/vmalloc
support.

Fixes: ce17347 ("riscv: mm: support Svnapot in huge vmap")
Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
pte_leaf_size() must be reimplemented to add support for NAPOT mappings.

Fixes: 82a1a1f ("riscv: mm: support Svnapot in hugetlb page")
Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
@bjoto
Copy link
Author

bjoto commented Feb 29, 2024

Upstream branch: 680945f
series: https://patchwork.kernel.org/project/linux-riscv/list/?series=830425
version: 1

@bjoto
Copy link
Author

bjoto commented Feb 29, 2024

At least one diff in series https://patchwork.kernel.org/project/linux-riscv/list/?series=830425 irrelevant now. Closing PR.

@bjoto bjoto added accepted and removed new labels Feb 29, 2024
@bjoto bjoto closed this Feb 29, 2024
@bjoto bjoto deleted the series/830425=>fixes branch February 29, 2024 22:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant