use with mprotect(2), but without enabling them immediately.
Extend the mremap(2) interface to allow duplicating mappings, i.e.
create a second range of virtual addresses references the same physical
pages. Duplicated mappings can have different effective protections.
Adjust PAX mprotect logic to disallow effective protections of W&X, but
allow one mapping W and another X protections. This obsoletes using
temporary files for purposes like JIT.
Adjust PAX logic for mmap(2) and mprotect(2) to fail if W&X is requested
and not silently drop the X protection.
Improve test cases to ensure correct operation of the changed
interfaces.
PT_SETSTEP and PT_CLEARSTEP in the current design must unlock proc_lock and
t->p_lock. These functions use lwp_delref() for a tracee with more than one
LWP. This function internally lock (t->)p_lock and this is lock against
self.
There are coming new ATF test with PT_*STEP with multiple LWPs to catch
these bugs in future changes.
Sponsored by <The NetBSD Foundation>
at the place we expected it to be attached!
As mentioned several times (on tech-kern@ mailing list) over the past
18 months or so, I've seen a few instances where this will trigger,
although I've been unable to reproduce them. Hopefully some wider
exposure will reveal the under-lying cause of this rare phenomenon.
Commit was proposed on tech-kern list, and no objections raised.
lwp_create() has been acquired more arguments, there was missing the latest
one. Per analogiam with changes in the same commit to other source files,
go for &SS_INIT.
Print e_ident[EI_MAG3] (it was missed)
Print e_ident[EI_CLASS] as it is used do determine correct ELF magic.
No functional change for non-debug (without option DEBUG_ELF) build.
- remove now unused field mnt_list.
- rename mount_list to mountlist and make it local to vfs_mount.c.
- make mountlist_lock local to vfs_mount.c.
Change pstat.c to retrieve vnodes by lru lists.
Don't count arguments that have WILLRELE/WILLPUT; count arguments
that are struct vnode *.
No functional change currently because it happens that every released
or put vnode argument comes first or after other ones.
Breaks file systems for which VOP_UNLOCK doesn't work on a reclaimed
vnode.
The only case in tree right now is sys/fs/union -- most file systems
use genfs_unlock, which does work on a reclaimed vnode.
Maybe we can work around this -- and still enable VOP_RECLAIM's
callees to assert lock ownership -- by having VOP_RECLAIM unlock the
vnode instead.
No bump because it wouldn't have been possible to acquire the lock in
VOP_RECLAIM anyway -- instant deadlock because vn_lock waits to
transition out of the RECLAIMING state first. Benefit is that we can
now assert ownership of the lock in any operations called by
VOP_RECLAIM.
Discussed on tech-kern:
https://mail-index.netbsd.org/tech-kern/2017/04/01/msg021751.html
