From: Jamie Iles <jamie.iles@oracle.com>
To: Sasha Levin <sasha.levin@oracle.com>
Cc: Jamie Iles <jamie.iles@oracle.com>,
mingo@kernel.org, peterz@infradead.org, penberg@kernel.org,
acme@ghostprotocols.net, paulus@samba.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 09/11] liblockdep: support using LD_PRELOAD
Date: Fri, 8 Feb 2013 10:43:18 +0000 [thread overview]
Message-ID: <20130208104318.GG3468@cedar> (raw)
In-Reply-To: <5113BABA.6010306@oracle.com>
On Thu, Feb 07, 2013 at 09:31:22AM -0500, Sasha Levin wrote:
> On 02/07/2013 05:28 AM, Jamie Iles wrote:
> >> +int pthread_rwlock_init(pthread_rwlock_t *rwlock,
> >> > + const pthread_rwlockattr_t *attr)
> >> > +{
> >> > + if (ll_pthread_rwlock_init == NULL)
> >> > + init_preload();
> > Why is this one special, doesn't init_preload being a constructor make
> > this redundant?
>
> I was testing it on different things, and stumbled on an interesting case:
> when pthread_mutex was taken from the constructor of a different module.
>
> In that case, the other constructor would try to init the mutex and take
> a lock, but we would segfault because we haven't resolved the pthread
> symbols yet ourselves (since our constructor was yet to be called).
Okay, that makes sense, but shouldn't we do this for all of the lock
operations? pthread locks can be statically initialized and they are
initializaed lazily on the first access so I think that this could
happen on any of the lock operations.
Jamie
next prev parent reply other threads:[~2013-02-08 10:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-06 22:11 [PATCH 00/11] lockdep: LD_PRELOAD support Sasha Levin
2013-02-06 22:11 ` [PATCH 01/11] liblockdep: remove the need for liblockdep_init Sasha Levin
2013-02-06 22:11 ` [PATCH 02/11] liblockdep: remove the need for liblockdep_set_thread Sasha Levin
2013-02-06 22:11 ` [PATCH 03/11] perf: stop using liblockdep_init and liblockdep_set_thread Sasha Levin
2013-02-06 22:11 ` [PATCH 04/11] liblockdep: fix AA test Sasha Levin
2013-02-06 22:11 ` [PATCH 05/11] liblockdep: correct the ABCDBCDA test Sasha Levin
2013-02-06 22:11 ` [PATCH 06/11] liblockdep: rbtree support Sasha Levin
2013-02-06 22:11 ` [PATCH 07/11] liblockdep: prevent multiple declarations of CALLER_ADDR0 Sasha Levin
2013-02-06 22:11 ` [PATCH 08/11] liblockdep: keep headers declarations even if lib is disabled Sasha Levin
2013-02-06 22:11 ` [PATCH 09/11] liblockdep: support using LD_PRELOAD Sasha Levin
2013-02-07 10:28 ` Jamie Iles
2013-02-07 14:31 ` Sasha Levin
2013-02-08 10:43 ` Jamie Iles [this message]
2013-02-08 23:55 ` Sasha Levin
2013-02-06 22:11 ` [PATCH 10/11] liblockdep: add tests for the LD_PRELOAD feature Sasha Levin
2013-02-06 22:11 ` [PATCH 11/11] liblockdep: preload helper Sasha Levin
2013-02-07 6:19 ` Namhyung Kim
2013-02-07 6:55 ` Namhyung Kim
2013-02-07 14:29 ` Sasha Levin
2013-02-07 7:07 ` [PATCH 00/11] lockdep: LD_PRELOAD support Pekka Enberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130208104318.GG3468@cedar \
--to=jamie.iles@oracle.com \
--cc=acme@ghostprotocols.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulus@samba.org \
--cc=penberg@kernel.org \
--cc=peterz@infradead.org \
--cc=sasha.levin@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).