The global allocator panics when out of memory rather than returning an
errors. In addition there are plenty of other places where we don't
handle allocation failure anyway. At some point in the future we should
systematically handle out of memory conditions, but until then let's not
pretend we do and get rid of the usage of the unstable allocator_api
feature that is unlikely to get stabilized any time soon.
This avoids the need to explicitly set a logger early during boot, which
reduces the amount of moving parts that could go wrong slightly. And it
cuts the kernel image size by 13kb.
Previously the deallocation would be rounded to the next power of two
preventing partial deallocation. But more importantly previously trying
to free phys_contiguous frames while another processes still borrows
them. Now this should just cause the deallocation to be delayed.
Before it was first add_ref'ed by `borrow_frame_enforce_rw_allocated`,
manually and then by `allocated_shared_one_page`.
Now it is only done by `borrow_frame_enforce_rw_allocated` and does not
get unref-ed as take() is called on the returned `RaiiFrame`.
Now the page is manually mapped and an `Allocated` type grant is
constructed (synonymous to `MAP_PRIVATE`). Before by using `allocated_shared_one_page`
an `AllocatedShared` provided grant was constructed (synonymous to
`MAP_SHARED`), which was wrong as the TCB would've not got CoW-ed
after fork(), making the Tcb malformed.
Signed-off-by: Anhad Singh <andypython@protonmail.com>
Diagonal as in
Thread A Thread B
Send to B Send to A
Wait for B Wait for A.
I haven't reproduced this bug, but this should fix it, since the wait
steps now checks the local percpu block for pending TLB shootdowns onto
itself.
This fixes a possible file table leak if a filetable contains an fd
referring (strongly) to the filetable itself. Now, it will automatically
be downgraded to a weak reference after it becomes a context's active
file table.
TODO: maybe support consuming a context's filetable to get a strong
reference back, provided it's exclusively owned.
Previously trying to funmap an address after the start of the grant
would result in an overflow only caught when compiling the kernel with
debug assertions enabled.
bjorn3