Bug 250271 - [arm64] Weird pmap bug when using O_WRONLY and mmap with PROT_WRITE
Summary: [arm64] Weird pmap bug when using O_WRONLY and mmap with PROT_WRITE
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-arm (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-11 12:51 UTC by Emmanuel Vadot
Modified: 2020-10-13 11:24 UTC (History)
2 users (show)

See Also:


Attachments
repro (1.14 KB, text/plain)
2020-10-11 12:51 UTC, Emmanuel Vadot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Emmanuel Vadot freebsd_committer freebsd_triage 2020-10-11 12:51:49 UTC
Created attachment 218664 [details]
repro

There is a weird pmap bug that prevent us of opening a file in O_WRONLY and mmap it with PROT_WRITE.
mmap success (MAP_FAILED isn't returned) but we receive sigsegv with SEGV_ACCERR as the code.
This was found in pkg (See PR 250059).

Attached is a small program to reproduce the bug, it works on all other platform for what I could see.
This mimic what pkg is doing and could probably be smaller but ...
Just create a directory, add file.sample in this directory and put some data in it and run ./prog directory
It should copy the content of the 'file.sample' to 'file' but instead segfault.
Comment 1 Jason A. Harmening freebsd_committer freebsd_triage 2020-10-12 06:05:22 UTC
I don't know if this works, since I don't have arm64 hardware or a qemu instance to test with, but could you try this?

Index: sys/arm64/arm64/trap.c
===================================================================
--- sys/arm64/arm64/trap.c      (revision 366629)
+++ sys/arm64/arm64/trap.c      (working copy)
@@ -301,7 +301,7 @@
                break;
        default:
                ftype = (esr & ISS_DATA_WnR) == 0 ? VM_PROT_READ :
-                   VM_PROT_READ | VM_PROT_WRITE;
+                   VM_PROT_WRITE;
                break;
        }
Comment 2 Emmanuel Vadot freebsd_committer freebsd_triage 2020-10-12 14:00:56 UTC
(In reply to Jason A. Harmening from comment #1)

Yeah andrew@ send me this exact same patch yesterday and it fixes the issue.
Comment 3 Jason A. Harmening freebsd_committer freebsd_triage 2020-10-12 23:02:27 UTC
Good to know, I'll back off and wait for Andrew to make the fix then.
Comment 4 Emmanuel Vadot freebsd_committer freebsd_triage 2020-10-13 11:24:24 UTC
Fixed in https://svnweb.freebsd.org/base?view=revision&revision=366665