[PATCH 2/3] dl-load: enforce soname uniqueness of loaded libraries
Wed Jun 10 00:15:01 GMT 2020
Sorry to hear that. If you have any feedback you wish to share either
publicly or privately about the process, please don't hesitate to reach
On 6/9/20 4:31 PM, Nicolas Viennot wrote:
> Hello Carlos,
> I wanted to let you know that the copyright issue has not been solved between my employer and GNU.
> I have exhausted the amount of time I want to spend on this issue, so I am abandoning the patches.
> Thank you for the time you spent into this.
> -----Original Message-----
> From: Carlos O'Donell <email@example.com>
> Sent: Saturday, February 1, 2020 12:49 AM
> To: Nicolas Viennot <Nicolas.Viennot@twosigma.com>; firstname.lastname@example.org
> Subject: Re: [PATCH 2/3] dl-load: enforce soname uniqueness of loaded libraries
> On 1/6/20 10:44 AM, Nicolas Viennot wrote:
>> When loading a new library of name `libname`, the loader currently
>> checks if any of the already loaded libraries have the soname `libname`.
>> If so, it returns the already loaded library of soname `libname`. If
>> not, it checks for the corresponding file `libname` on disk and
>> compares the device and inode number of already loaded libraries. If
>> there is a match, it returns the already loaded library of the same inode number.
>> If not, it proceeds to load the library of path is `libname`.
>> This patch adds the additional check of comparing the soname of the
>> newly loaded library with the sonames of already loaded libraries.
>> This new behavior enforces that no two loaded libaries have the same
>> soname, bringing a sane property in the system.
>> Note that this edge case can be encountered during a system upgrade,
>> or when using certain configuration of file system mounts, where
>> inodes cannot be relied upon.
> Thank you for working on this! This does look like an interesting patch and provides belt-and-suspenders and in general making the loader more robust against such odd failures is a good idea. We often see such things as crashes when systems are being live updated by rpm/dpkg etc.
> Before we can accept any contributions we need a copyright assignment from you for glibc. This is handled by the FSF.
> "FSF copyright Assignment"
> I suggest the futures assignment:
> This would allow us to accept this patch and all subsequent patches you would want to submit. Given that you're submitting from a corporate email it may require you to check to see if your employer owns the copyright of your work, in which case they would need to sign a corporate assignment. The FSF will help you through this process, and we accept digital assignments now so the process is faster than ever before.
> Please also have a look at the "Contribution Checklist":
> Thank you again for your patches! I look forward to your contributions!
More information about the Libc-alpha