Date: Tue, 23 Aug 2011 05:58:14 -0700 From: mdf@FreeBSD.org To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: skipping locks, mutex_owned, usb Message-ID: <CAMBSHm-nT5-wTbAFqsJ6ZjCPE9Vfxeva1F3zwWSAK8Ecw=8VsA@mail.gmail.com> In-Reply-To: <4E53986B.5000804@FreeBSD.org> References: <4E53986B.5000804@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 23, 2011 at 5:09 AM, Andriy Gapon <avg@freebsd.org> wrote:
> III. With my stop_scheduler_on_panic patch ukbd_poll() produces infinite chains
> of 'infinite' recursion because mtx_owned() always returns false. This is because
> I skip all lock/unlock/etc operations in the post-panic context. I think that
> it's a good philosophical question: what operations like mtx_owned(),
> mtx_recursed(), mtx_trylock() 'should' return when we actually act as if no locks
> exist at all?
>
> My first knee-jerk reaction was to change mtx_owned() to return true in this
> "lock-less" context, but _hypothetically_ there could exist some symmetric code
> that does something like:
> func()
> {
> if (mtx_owned(&Giant)) {
> mtx_unlock(&Giant);
> func();
> mtx_lock(&Giant);
> return;
> }
>
> // etc ...
>
> What do you think about this problem?
Given that checking for a lock being held is a lot more common than
checking if it's not held (in the context of mtx_assert(9) and
friends), it seems reasonable to report that a lock is held in the
special context of after panic.
> That question III actually brings another thought: perhaps the whole of idea of
> skipping locks in a certain context is not a correct direction?
> Perhaps, instead we should identify all the code that could be legitimately
> executed in the after-panic and/or kdb contexts and make that could explicitly
> aware of its execution context. That is, instead of trying to make _lock,
> _unlock, _owned, _trylock, etc do the right thing auto-magically, we should try to
> make the calling code check panicstr and kdb_active and do the right thing on that
> level (which would include not invoking those lock-related operations or other
> inappropriate operations).
I don't think it's possible to identify all the code, since what runs
after panic isn't tested very much. :-) I don't disagree that one
should think about the issue, but providing reasonable defaults like
skipping locks reduces the burden on the programmer.
Thanks,
matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMBSHm-nT5-wTbAFqsJ6ZjCPE9Vfxeva1F3zwWSAK8Ecw=8VsA>