[openib-general] Re: [PATCH] rdma_lat-09 and results

[Roland Dreier]

    Roland> It seems like the best would be to have libmthca.a in
    Roland> $(libdir) and mthca.so in $(libdir)/infiniband.  That way
    Roland> we make it easy to do static linking and avoid having two
    Roland> names for the same object.

    Michael> OK, but I dont know how to do that in autotools. Do you?

Not sure, I'll poke around a little.

    Michael> Actually, whats the importance of it? It seems the user
    Michael> can compile libibverbs as readily as the plugin ...

I think it's mostly useful once distributions start shipping
libibverbs.  It means someone can take binaries supplied by their
distros and just install a new plugin driver in ~user/whatever, and
then use whatever fancy new IB hardware they have.

It's similar to how I can put libjavaplugin_oji.so in ~/.mozilla/plugins
if I'm feeling impure.

    Michael> Solves this particular problem, but maybe, additionally,
    Michael> there should be a configuration option to disable
    Michael> OPENIB_DRIVER_PATH lookup?

Would anyone really use this?  How does it help?  For processes not
running SUID, a hostile user can already generate any conceivable
binary, link in any and all libraries, and set LD_PRELOAD to whatever.

    Michael> I also wander about the user of strdupa - can it cause
    Michael> stack overflow?

I doubt an environment variable can be made long enough to overflow
the stack, but even if it can, who cares?  We can only hit that
strdupa() if the processes EUID == real UID, and in that case the user
could already just run a program like

	while (1) { alloca(1000000); }

 - R.