Peter, Thanks for your comments! I'll address them and re-send the patch series.
On 05/08/2013 06:22 AM, Peter Zijlstra wrote: >> + /* >> > + * Some programs attempt to initialize and use locks in their >> > + * allocation path. This means that a call to malloc() would >> > + * result in locks being initialized and locked. >> > + * >> > + * Why is it an issue for us? dlsym() below will try allocating to >> > + * give us the original function. Since this allocation will result >> > + * in a locking operations, we have to let pthread deal with it, >> > + * but we can't! we don't have the pointer to the original API >> > + * since we're inside dlsym() trying to get it :( >> > + * >> > + * We can work around it by telling the program that locking was >> > + * really okay, and just initialize those locks when we're fully >> > + * up and running (this is ok because this all happens during >> > + * initialization phase, when we have just one thread). But >> > + * this is a big TODO at this point. >> > + */ > Fun.. got any example programs that trigger this? firefox. The problem there is that it uses jemalloc, which tries to do what I've described in the blurb above. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
