lkml.org 
[lkml]   [1998]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: shared memory deallocation
Umm, yeah. That's what it's supposed to do. Shared memory is supposed to
be persistant, so that you can access it from other processes even if no
processes have been using it in the meantime.

D


Bevan Schroeder wrote:
>
> Having been raised to be a slacker coder by garbage-collecting UNIX
> environments, I was a bit surprised when linux failed to do anything about
> the shared memory I had allocated for use with XLib. In retrospect, it
> makes sense, but the damage was done, and I had a 60MB+ memory leak on a
> system that can't spare quite that much. I looked through ipc/shm.c for
> structures that at least kept track of these pointers so that I could
> write a program that would look them up and shmdt() them, but nothing
> obvious bit me: is there anything in /proc or otherwise user-accessible
> that lists shared memory pointers that are currently allocated?
> Given a system with malicious users, this seems like a particularly
> attractive DoS attack - sysadmins either have to reboot all the time or
> limit memory allocation, and the latter is unpleasant to do even if it
> works...
>
> -bevan
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d- s++: a C++++$ UL++++B+++S+++C++H++U++V+++$ P+++$ L+++ E-
W+++(--)$ N++ w++$>--- t+ 5++ X+() R+ tv b++++ DI+++ e- h-@
------END GEEK CODE BLOCK------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [from the cache]
©2003-2011 Jasper Spaans