Date: Thu, 22 Feb 2018 09:18:11 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: John Baldwin <jhb@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r329796 - head/sys/dev/vt Message-ID: <dbeaf5a3-e83d-3006-6482-23f6ddceebfb@FreeBSD.org> In-Reply-To: <201802220226.w1M2QTR2068451@repo.freebsd.org> References: <201802220226.w1M2QTR2068451@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22/02/2018 04:26, John Baldwin wrote: > Author: jhb > Date: Thu Feb 22 02:26:29 2018 > New Revision: 329796 > URL: https://svnweb.freebsd.org/changeset/base/329796 > > Log: > Avoid grabbing locks when grabbing the vt(4) console for DDB. > > Trying to grab locks during cngrab() when entering the debugger is > deadlock prone as all other CPUs are already halted (and thus unable > to release locks) when cngrab() is invoked. One could instead use > try-locks. However, the case that the try-lock fails still has to > be handled. In addition, if the try-lock works it doesn't provide > any greater ordering guarantees than is already provided by entering > and exiting DDB. It is simpler to define a simpler path for the > case that the try-lock would fail and always use that when entering > DDB. Messing with timers, etc. when entering DDB is dubious even if > the try-lock succeeds. > > This patch attempts to use the smallest possible set of operations to > grab the vt(4) console when entering DDB without using any locks. > > Reviewed by: emaste > Tested by: Matthew Macy > MFC after: 1 week There are some additional, harder problems in that path: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213334 -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?dbeaf5a3-e83d-3006-6482-23f6ddceebfb>