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

[Shyam]

On 07/30/2015 10:57 AM, 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].
>
> Similar issue with respect to uuid* routines was already reported in [3].
>
> To avoid such issues, it may be better and a cleaner way to mark all the
> xlator fops static, like in [4].

Should we consider restricting symbols exported from a shared library? 
like, 
https://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html

<extract> "The programmer specifies a “hidden” attribute for all files 
that make up the shared library, and an “exported” attribute for those 
symbols in these files that shall be exported." </extract>

Even -export-symbols has been effective in the past for me.

I think that marking xlator FOPs as static may not be enough, we may 
require to restrict other symbols that are inadvertently exported as well.

>
> We have raised bug1248669 to track all the required changes. Request the
> component maintainers to take a look and change the respective xlator
> fop definitions.
>
> Thanks,
> Soumya
>
> [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1245636#c6
> [2] - https://bugzilla.redhat.com/show_bug.cgi?id=1248669
> [3] - http://article.gmane.org/gmane.comp.file-systems.gluster.devel/10074
> [4] - http://review.gluster.org/#/c/11805
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel