[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: malloc() patches round 3
From: |
Thomas Bushnell, BSG |
Subject: |
Re: malloc() patches round 3 |
Date: |
22 Aug 2001 16:42:31 -0700 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
Igor Khavkine <i_khavki@alcor.concordia.ca> writes:
> There are still problems in libpager though. In
> _pager_lock_object() and pager_change_attributes(), malloc() is used
> without its return value being checked. Both functions are void and
> the semantics of their use (as far as I can tell) do not allow to
> check for errors easily.
In _pager_lock_object, malloc is only used when SYNC is true. This is
an internal route, and how errors might get sent up depends on the
caller. The possibilities are:
_pager_seqnos_memory_object_data_unlock:
The kernel is asking for permission to write the page. The
synchronous call to lock_object occurs if the library user says the
unlock cannot succeed and an error should be sent to the kernel. We
*must* synchronously flush the page before marking the error bit
set (with _pager_mark_request_next_error). The sequel is that the
kernel requests the page back and gets an error.
The only fix I can think of in the event of memory exhaustion is to
delay and retry.
pager_flush, pager_flush_some, pager_return, pager_return_some,
pager_sync, pager_sync_some:
These are library user functions; they could be changed to return
errors. Note however that most of their callers cannot tolerate
errors.
Similar comments apply to pager_change_attributes.
> Since this is a support library, I would prefer that it did not by itself
> terminate the running process under any circumstances and propagted
> all errors to the programs that use it, however there are always excetions.
> So should the fix be a simple assert() statement or shoul I look into
> libpager in more detail to be able to propagate these errors?
I would prefer assert().
I have no objection to being more diligent about checking malloc
returns, but I have *NEVER* seen a Unixoid system perform anything
like sensibly in the event of virtual memory exhaustion. The Mach
kernel itself just crashes directly. And that's *better* than
diligently returning errors and trying to poke along, because it
actually *fixes* the problem: the system comes up again, and works.
Every system I've seen, when memory exhaustion happens, simply never
functions right again until rebooted.
- malloc() patches round 3, Igor Khavkine, 2001/08/22
- Re: malloc() patches round 3, Marcus Brinkmann, 2001/08/22
- Re: malloc() patches round 3,
Thomas Bushnell, BSG <=
- Re: malloc() patches round 3, Igor Khavkine, 2001/08/22
- Re: malloc() patches round 3, Thomas Bushnell, BSG, 2001/08/22
- Re: malloc() patches round 3, Igor Khavkine, 2001/08/22
- Re: malloc() patches round 3, Thomas Bushnell, BSG, 2001/08/22
- Re: malloc() patches round 3, Ognyan Kulev, 2001/08/23
- Re: malloc() patches round 3, Jeroen Dekkers, 2001/08/23
- Re: malloc() patches round 3, eric . rannaud . liste, 2001/08/24
- Re: malloc() patches round 3, Brent A. Fulgham, 2001/08/25
- Re: malloc() patches round 3, Chiaki Ishikawa, 2001/08/23
Re: malloc() patches round 3, Niels Möller, 2001/08/23