[Gluster-devel] Mark all the xlator fops 'static '

[Kaleb S. KEITHLEY]

On 07/30/2015 05:16 PM, Niels de Vos wrote:
> On Thu, Jul 30, 2015 at 08:27:15PM +0530, Soumya Koduri wrote:
>> Hi,
>>
>> With the applications using and loading different libraries, the function
>> symbols with the same name may get resolved incorrectly depending on the
>> order in which those libraries get dynamically loaded.
>>
>> Recently we have seen an issue with 'snapview-client' xlator lookup fop -
>> 'svc_lookup' which matched with one of the routines provided by libntirpc,
>> used by NFS-Ganesha. More details are in [1], [2].
> 
> Indeed, the problem seems to be caused in an execution flow like this:
> 
> 1. nfs-ganesha main binary starts
> 2. the dynamic linker loads libntirpc (and others)
> 3. the dynamic linker retrieves symbols from the libntirpc (and others)
> 4. 'svc_lookup' is amoung the symbols added to a lookup table (or such)
> 5. during execution, ganesha loads plugins with dlopen()
> 6. the fsalgluster.so plugin is linked against libgfapi and gfapi gets
>    loaded
> 7. libgfapi retrieves the .vol file and loads the xlators, including
>    snapview-client
> 8. snapview-client provices a 'svc_lookup' symbol, same name as
>    libntirpc provides, complete different functionality

So far so good. But I would have expected the compiler to have populated
the function pointers in snapview-client's fops table at compile time;
the dynamic loader should not have been needed to resolve
snapview-client's svc_lookup, because it was (should have been) already
resolved at compile time.

And in fact it is, but, there are semantics for global (.globl) symbols
and run-time linkage that are biting us.


-- 

Kaleb