| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were previously unconditionally adding PROT_WRITE to the maxprot of
private mapping (because a private mapping can be written even if the
fd is read-only), but this might violate the user's PROT_MAX request.
While here, rename cap_maxprot to max_maxprot. This is the intersection
of the maximum protections imposed by capsicum rights on the fd (not
really relevant for private mappings) and the user-required maximum
protections (which were not being obeyed). In particular, cap_maxprot
is a misnomer after the introduction of PROT_MAX.
Add some regression test cases. mmap__maxprot_shm fails without this
patch.
Note: Capsicum's CAP_MMAP_W is a bit ambiguous. Should it be required
in order to create writeable private mappings? Currently it is, even
though such mappings don't permit writes to the object referenced by the
fd.
Reported by: brooks
Reviewed by: brooks
MFC after: 1 month
Fixes: c7841c6b8e41 ("Relax restrictions on private mappings of POSIX shm objects.")
Differential Revision: https://reviews.freebsd.org/D46741
|
|
|
|
| |
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
|
|
|
|
|
|
|
|
|
|
| |
Use kern.elfXX.allow_wx to decide whether to map W+X or W-only memory.
Future work could expand this test to add an "allow_wx" axis to the
test matrix, but I would argue that a separate test should be written,
since that's orthogonal to map_at_zero.
MFC after: 1 week
Sponsored by: Dell EMC Isilon
|
|
|
|
|
|
|
|
|
|
|
|
| |
When trapping on a wrote access to a buffer the kernel has mapped as write
only we should only pass the VM_PROT_WRITE flag. Previously the call to
vm_fault_trap as the VM_PROT_READ flag was unexpected.
Reported by: manu
Sponsored by: Innovate UK
Notes:
svn path=/head/; revision=366665
|
|
|
|
|
|
|
|
| |
PR: 216976
Sponsored by: Dell EMC Isilon
Notes:
svn path=/head/; revision=313657
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some recent changes to vm related to mmap(2) have broken the prot checks that
would result with an EINVAL with this case
I suspect r313352 is the root-cause the issue
PR: 216976
Sponsored by: Dell EMC Isilon
Notes:
svn path=/head/; revision=313565
|
|
|
|
|
|
|
|
|
|
| |
The loop index (i) doesn't need to be size_t as its comparison is signed
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Notes:
svn path=/head/; revision=312110
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- close file descriptors after use.
- Always munmap memory regions after mmap'ing them.
- Make sure getpagesize() returns a value greater than 0 and use a
cached value instead of always calling getpagesize(3).
CID: 1331374-1331377, 1331653-1331662
Differential Revision: https://reviews.freebsd.org/D6011
MFC after: 2 weeks
Reported by: Coverity
Reviewed by: cem
Sponsored by: EMC / Isilon Storage Division
Notes:
svn path=/head/; revision=298301
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add cdev-related tests for bad args.
- Add two simple tests cases for mapping /dev/zero that test for
MAP_ANON-like behavior.
Reviewed by: alc, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D3323
Notes:
svn path=/head/; revision=287448
|
|
|
|
|
|
|
|
|
|
| |
trigger failures.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D3269
Notes:
svn path=/head/; revision=286370
|
|
|
|
|
|
|
|
|
|
| |
facilitate adding more mmap() tests.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D3268
Notes:
svn path=/head/; revision=286369
|
|
As jhb noted, the actual mmap(2) implementation is under sys/vm, not
sys/kern/, so the correct logical place is tests/sys/vm/, not
tests/sys/kern/
X-MFC with: r282076
MFC after: 6 days
Notes:
svn path=/head/; revision=282104
|