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
View All Add an attachment (proposed patch, testcase, etc.)

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