lkml.org 
[lkml]   [1997]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectIPC_PRIVATE dealloc (Re: Possible Kernel Memory Leak...)
Date
Shigeru IKEDA  <si@injapan.net> wrote:
> > any rate, this deallocates the memory and stabilized my system.. Is there
> > any reason why shared memory belonging to defunct processes is not
> > automatically deallocated?
> Shared memory is used in various ways. And often is shared by several
> processes. (So it's named 'shared'.)

Yes, but in this case it is allocated with a known fixed or
ftok()-obtained key, not with IPC_PRIVATE. Resources allocated with
IPC_PRIVATE (which returns a random, rather than derived from the key,
handle) become unaccessible once the last descendant of the allocating
process dies - there is no way any subsequent shmget() will return the
same handle. Resources allocated with a real key remain accessible by
new processes using the same key.

So what would be needed is some special-casing in the kernel for
IPC_PRIVATE allocation. Like files or other resource, they should get
deallocated when the last acceess path vanishes. There is no reason to
keep them.

We could implement this by keeping a usage count on every IPC handle.
For non-IPC_PRIVATE allocation, it is -1 meaning "don't care",
otherwise it counts how many processes know this handle, getting
updated on every fork() and exit(). If it reaches zero, the resource
is freed.

(Of course this applies to all types of SysV IPC resources.)

olaf
--
___ Olaf.Titz@inka.de or @{stud,informatik}.uni-karlsruhe.de ____
__ o <URL:http://www.inka.de/~bigred/> <IRC:praetorius>
__/<_ >> Just as long as the wheels keep on turning round
_)>(_)______________ I will live for the groove 'til the sun goes down << ____

\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.512 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site