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

From: Lev Olshvang <levonshe@yandex.com>
To: Greg KH <greg@kroah.com>
Cc: linux-il <linux-il@cs.huji.ac.il>,
	kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: How to signal kernel that shared library is not in use by any process anymore ?
Date: Thu, 27 Dec 2018 10:47:42 +0300	[thread overview]
Message-ID: <11849361545896862@myt5-a323eb993ef7.qloud-c.yandex.net> (raw)
In-Reply-To: <20181221153110.GA14584@kroah.com>

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
Lev

21.12.2018, 18:31, "Greg KH" <greg@kroah.com>:
> 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 ld-linux.so 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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies