Date: Tue, 30 Oct 2018 18:03:29 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Eric van Gyzen <vangyzen@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r339917 - head/sys/kern Message-ID: <81c706c9-9bea-0044-4e8c-406ca6ab5f1d@FreeBSD.org> In-Reply-To: <201810301454.w9UEsGeB097999@repo.freebsd.org> References: <201810301454.w9UEsGeB097999@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30/10/2018 16:54, Eric van Gyzen wrote: > Author: vangyzen > Date: Tue Oct 30 14:54:15 2018 > New Revision: 339917 > URL: https://svnweb.freebsd.org/changeset/base/339917 > > Log: > Always stop the scheduler when entering kdb > > Set curthread->td_stopsched when entering kdb via any vector. > Previously, it was only set when entering via panic, so when > entering kdb another way, mutexes and such were still "live", > and an attempt to lock an already locked mutex would panic. > > Reviewed by: kib, cem > Discussed with: jhb > Tested by: pho > MFC after: 2 months > Sponsored by: Dell EMC Isilon > Differential Revision: https://reviews.freebsd.org/D17687 My recollection from way back then is that the previous behavior was on purpose. The idea was that the kdb code and code hat services it should be written specifically to avoid taking locks used by general code. I am not sure if that approach had any practical benefits, just sharing the memory. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?81c706c9-9bea-0044-4e8c-406ca6ab5f1d>