Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Nov 2011 12:08:39 +0200
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Pawel Jakub Dawidek <pjd@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r227394 - in head/sys: amd64/amd64 i386/i386
Message-ID:  <20111110100839.GK50300@deviant.kiev.zoral.com.ua>
In-Reply-To: <20111110062322.GA1696@garage.freebsd.pl>
References:  <201111091725.pA9HPhXh092218@svn.freebsd.org> <20111109173128.GF50300@deviant.kiev.zoral.com.ua> <20111110062322.GA1696@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help

--Q7Dt3iDhSkbxWkBL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 10, 2011 at 07:23:23AM +0100, Pawel Jakub Dawidek wrote:
> On Wed, Nov 09, 2011 at 07:31:28PM +0200, Kostik Belousov wrote:
> > On Wed, Nov 09, 2011 at 05:25:43PM +0000, Konstantin Belousov wrote:
> > > Author: kib
> > > Date: Wed Nov  9 17:25:43 2011
> > > New Revision: 227394
> > > URL: http://svn.freebsd.org/changeset/base/227394
> > >=20
> > > Log:
> > >   Stopped process may legitimately have some threads sleeping and not
> > >   suspended, if the sleep is uninterruptible.
> > Even more, stopped process might have some threads still running in the
> > kernel mode, or inhibited due to wait on blockable locks. I was unable
> > to design an expression that would assert that such thread will be stop=
ped
> > at the kernel->user boundary.
> >=20
> > The assertion itself is useful and catched several bugs, but theoretica=
lly
> > can cause false positives. If any report of the fired assert for kernel=
-mode
> > thread is provided, I will remove the assertions.
>=20
> If in five years some change will make it to fire and you won't be
> around, nobody will remember this e-mail of yours and someone will spend
> time on looking for a bug that doesn't exist.
>=20
> If we know it can cause false positives, I'd be in favour of removing it
> or changing it into a warning or at the very least moving this
> information into commit log.
Yes, I do agree that removing the assertion is the most straightforward
solution, but on the assertion already catched more real bugs then
caused headaches (my headache, BTW). Either I change the third or condition
to plain P_SHOULDSTOP(), or create a way to assert exactly what I need.

--Q7Dt3iDhSkbxWkBL
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iEYEARECAAYFAk67oqcACgkQC3+MBN1Mb4i7UQCbBBAr44zlXh779kHR51peBQZP
pTUAnAgkhE+nhoHx84FAffaPMCq6ZIab
=P2mO
-----END PGP SIGNATURE-----

--Q7Dt3iDhSkbxWkBL--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111110100839.GK50300>