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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
