How to signal kernel that shared library is not in use by any process anymore ?

Lev Olshvang levonshe at
Thu Dec 27 02:47:42 EST 2018

Hello Greg,

Thanks for you your reply.
It help me to better express my question

>From the application I can access /proc/self/maps and see which memory is  mapped  for my library I do not intend to use after application passes init phase.
I would like to unmap this memory region, but since I do not have file descriptor for this so I can not do this.
Only kernel can unmap this memory for me,
I am willing to pass library name or address to system cal, but IMHO such system call does not exist.
Should I rely on memory manager which will use reuse this pages because they will never page faulted back ?

I am afraid that since this is C++ lib, some pages are modified and will not be considered clean ?

Thanks again for your precious time.
Perhaps somebody from the list can respond too.

Thank you all

21.12.2018, 18:31, "Greg KH" <greg at>:
> On Fri, Dec 21, 2018 at 05:20:36PM +0300, Lev Olshvang wrote:
>>  Hi All,
>>  I have an executable (C++) which is the exclusive user of the some shared library that it uses only during the initialization phase.
>>  I would like to free memory used by this shared library, because I am running on embedded system.
>>  How can I achieve this?
>>  I know that dlopen() will load shared library, and hope that following dlclose() will free this lib memory.
> That right there is how you "achieve" this, call dlclose() and all will
> be fine. If your system needs the memory that was being used, it will
> reclaim it from the memory that was previously being used by the library
> at this point in time.
> Nothing else needs to be done.
> Have you tested this and found it not to work properly?
>>  1. Still I do not know what method should be used to make dynamic linker look again into executable and resolve symbols of the newly appeared symbols ?
> What "newly appeared symbols"?
> If you need to load the library again, call dlopen().
>>  2. And how to tell the dynamic linker to postpone the symbol resolution until dlopen() will load the library?
> It will not happen until you tell it to, right?
>>  3. Whether to compile and link executable with this library or leave unresolved symbols?
> It sounds like you don't really know what type of problem you are trying
> to solve here.
> Back up, what is the real issue you are having with the kernel at this
> point in time?
> thanks,
> greg k-h

More information about the Kernelnewbies mailing list