Date: Tue, 21 Sep 2010 09:31:01 -0700 From: mdf@FreeBSD.org To: Andriy Gapon <avg@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r212964 - head/sys/kern Message-ID: <AANLkTim%2BZYppETzFOYrGjhsEXr9hVPi8L0Mvaa6RkhMq@mail.gmail.com> In-Reply-To: <4C98D200.4040909@freebsd.org> References: <201009211507.o8LF7iVv097676@svn.freebsd.org> <AANLkTi=CTr%2BZDs3znsF-SXDp__xxbetjnhSBxiDhfFYy@mail.gmail.com> <4C98CEE7.6060802@freebsd.org> <4C98D200.4040909@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 21, 2010 at 8:40 AM, Andriy Gapon <avg@freebsd.org> wrote: > on 21/09/2010 18:27 Andriy Gapon said the following: >> on 21/09/2010 18:17 mdf@FreeBSD.org said the following: >>> >>> I'd recommend using stack_print_ddb(), as that avoids any locking >>> which may hang depending on how the kernel panic'd. >> >> It seems that stack_print_ddb() depends on DDB? > > But the point about locking is very good. > How do you suggest we can deal with it? > > A dirty hack would be to check panicstr in linker_search_symbol_name and avoid > locking, but I don't like that at all. > Perhaps, some code in subr_stack.c could be taken outside DDB ifdef? I keep forgetting, but actually _mtx_lock_sleep() will just return if panicstr is set. _mtx_assert() is similarly guarded, so actually it should be mostly okay. Thanks, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTim%2BZYppETzFOYrGjhsEXr9hVPi8L0Mvaa6RkhMq>