| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
The locking order between map locks and page "busy" locks
is that the page "busy" lock comes first, but uvm_map_clean()
breaks this rule by holding a map locked (as reader) while
waiting for page "busy" locks.
If another thread is in the page-fault path holding a page
"busy" lock while waiting for the map lock (as a reader)
and at the same time a third thread is blocked waiting for
the map lock as a writer (which blocks the page-fault thread),
then these three threads will all deadlock with each other.
Fix this by marking the map "busy" (to block any modifications)
and unlocking the map lock before possibly waiting for any
page "busy" locks.
Martin Pieuchot reported that the same problem existed in OpenBSD
he applied this fix there after several people tested it.
fixes PR 56952
|
|
|
|
|
|
arrays to use DEVMAP_ENTRY{,_END}
|
|
No functional change intended.
|
|
|
|
|
|
While here, print some of the inputs with KASSERTMSG.
|
|
|
|
NFCI.
|
|
Discussed on tech-kern:
https://mail-index.netbsd.org/tech-kern/2023/02/23/msg028729.html
|
|
|
|
|
|
pmap_md_pdetab_init.
Call pmap_md_pdetab_fini from pmap_segtab_destroy.
|
|
the swap/drum block device was never intended to allow user opens,
but when the internal VOP_OPEN() in uvm_swap_init() was added
back in rev 1.135, the d_open method was changed from always-fail
to always-succeed in order to allow the new initial internal open.
this had the side effect of incorrectly allowing user opens too.
fix this by replacing the swap_bdevsw d_open with one that succeeds
for the first call but fails for all subsequent calls.
Reported-by: syzbot+90a23d2f19e5a0a302b3@syzkaller.appspotmail.com
|
|
PR kern/56900
Reported-by: syzbot+3833ae1d38037a263d05@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=e542bcf59b2564cca1cb38c12f076fb08dcac37e
|
|
|
|
|
|
|
|
|
|
|
|
otherwise concurrent updates might both think they've updated the entry.
|
|
|
|
|
|
|
|
This can be included unconditionally, and db_active can then be
queried unconditionally; if DDB is not in the kernel, then db_active
is a constant zero. Reduces need for #include opt_ddb.h, #ifdef DDB.
|
|
|
|
This is based on code given to me by Matt Thomas a long time ago with
many updates and bugs fixes from me.
|
|
|
|
|
|
pmap_pdetab_t *ptb. pmap_pdetab_t *ptp would be far too confusing.
NFC. Same code before and after.
|
|
|
|
|
|
|
|
- Need sys/types.h for vaddr_t, paddr_t, u_int, &c.
- Forward-declare struct vm_page so we don't have to rely on
machine/pmap.h to do so.
|
|
NKMEMPAGES_MAX_UNLIMITED. we used to limit kva to 1/8 of physmem
but limiting to 1/4 should be enough, and 1/4 still gives the kernel
enough kva to map all of the RAM that KMSAN has not stolen.
Reported-by: syzbot+ca3710b4c40cdd61aa72@syzkaller.appspotmail.com
|
|
high enough to allow the kernel to map all of RAM into kmem,
so that free physical pages rather than kernel virtual space is
the limiting factor in allocating kernel memory. this gives ZFS
more flexibility in tuning how much memory to use for its ARC cache.
|
|
|
|
They are not compile-time constants for sparc.
|
|
This useless garbage warning is apparently designed to make it
painful to write portable safe arithmetic and I think we ought to
just disable it.
|
|
XXX Not sure this should be allowed at all, but this way we don't
change the semantics of the existing code which was written under
essentially the assumption of -fwrapv.
|
|
|
|
Reported-by: syzbot+d5a96e7a0ebbd0b76dfc@syzkaller.appspotmail.com
|
|
No functional change intended, just sprinkling assertions to make it
clearer.
|
|
This is guaranteed by a test earlier; adding the assertion just makes
it clearer that it applies to the branch where we call fo_mmap -- no
functional change intended.
|
|
|