From 3e25a0fd194bbdb1838abb0a17832252eb03462a Mon Sep 17 00:00:00 2001 From: Joshua Branson Date: Wed, 7 Nov 2018 10:32:38 -0500 Subject: I am adding Richard's comment about mach's memory management issue to the open issues gnumach memory management page. I also added a link to the 64-bit port on the 830MB RAM limit page. --- open_issues/64-bit_port.mdwn | 2 +- open_issues/gnumach_memory_management.mdwn | 16 ++++++++++++++-- 2 files changed, 15 insertions(+), 3 deletions(-) (limited to 'open_issues') diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn index 8658f1b7..656dd450 100644 --- a/open_issues/64-bit_port.mdwn +++ b/open_issues/64-bit_port.mdwn @@ -19,7 +19,7 @@ What is left for initial support (32-on-64) is * adding 64bit boot support from grub * implement 32/64 RPC compatibility for RPCs served by kernel. -See http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00000.html +See [[http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00000.html]] For pure 64bit support, we need to diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index 8eb0cf8a..911c2b51 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -11,8 +11,6 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] -There is a [[!FF_project 266]][[!tag bounty]] on this task. - [[!toc]] @@ -2389,3 +2387,17 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. well, there is also a locking error in the slab allocator, although not a problem for a non preemptible kernel like gnumach non preemptible / uniprocessor + +## IRC freenode, #hurd, 2016-12-29 + + i've identified a fundamental flaw with the default pager + and actually, with mach in general i suppose + i assumed that it was necessary to trust the server only + that a server didn't need to trust its client + but mach messages carry memory that is potentially mapped from unprivileged pagers + which means faulting on that memory effectively makes the faulting process a client to the unprivileged pager + and that's something that can happen to the default pager during heavy memory pressure + in which case it deadlocks on itself because the copyout hangs on a fault, waiting for the unprivileged pager to provide the data + (which it can't because of heavy memory pressure and because it's unprivileged, it's blocked, waiting until allocations resume) + the pageout daemon will keep paging out to the default pager in the hope those pages get freed + but sending to the default pager is now impossible because its map is locked on the never-ending fault -- cgit v1.2.3