Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Aug 2016 08:23:43 -0700
From:      Bryan Drewery <bdrewery@FreeBSD.org>
To:        Warner Losh <imp@bsdimp.com>, "Kenneth D. Merry" <ken@freebsd.org>
Cc:        "Andrey V. Elsukov" <ae@freebsd.org>, Peter Wemm <peter@wemm.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, src-committers <src-committers@freebsd.org>
Subject:   Re: svn commit: r303019 - head/sys/geom
Message-ID:  <df6da7f2-ffc2-daca-aff5-0fd75fd6e83f@FreeBSD.org>
In-Reply-To: <CANCZdfq4FLQY3SugEvpMkRCQjhyCHfzFmuqf1m_Mw8LDBoRtLA@mail.gmail.com>
References:  <201607190536.u6J5aLl7015268@repo.freebsd.org> <3277576.dFZ2EGo2Fh@overcee.wemm.org> <6198652.UmU69kS6Zt@overcee.wemm.org> <181fcc35-3a5d-043f-7dc4-7a01a53eebae@FreeBSD.org> <7372bf93-69a2-f5f5-1d07-204fd31f252c@FreeBSD.org> <20160812151117.GA52309@mithlond.kdm.org> <CANCZdfqJ7_0PAKvvziscP1GJ%2BmVwtzkEhVt6kL7a1rVu1HZCXw@mail.gmail.com> <20160812151745.GA52527@mithlond.kdm.org> <CANCZdfq4FLQY3SugEvpMkRCQjhyCHfzFmuqf1m_Mw8LDBoRtLA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--cUcpUOGMI3scLeW38BQE1FqfCJfLSM1TH
Content-Type: multipart/mixed; boundary="srVN6Bwftn190dQEXwoKeebQISJUiN0dC"
From: Bryan Drewery <bdrewery@FreeBSD.org>
To: Warner Losh <imp@bsdimp.com>, "Kenneth D. Merry" <ken@freebsd.org>
Cc: "Andrey V. Elsukov" <ae@freebsd.org>, Peter Wemm <peter@wemm.org>,
 "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>,
 "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>,
 src-committers <src-committers@freebsd.org>
Message-ID: <df6da7f2-ffc2-daca-aff5-0fd75fd6e83f@FreeBSD.org>
Subject: Re: svn commit: r303019 - head/sys/geom
References: <201607190536.u6J5aLl7015268@repo.freebsd.org>
 <3277576.dFZ2EGo2Fh@overcee.wemm.org> <6198652.UmU69kS6Zt@overcee.wemm.org>
 <181fcc35-3a5d-043f-7dc4-7a01a53eebae@FreeBSD.org>
 <7372bf93-69a2-f5f5-1d07-204fd31f252c@FreeBSD.org>
 <20160812151117.GA52309@mithlond.kdm.org>
 <CANCZdfqJ7_0PAKvvziscP1GJ+mVwtzkEhVt6kL7a1rVu1HZCXw@mail.gmail.com>
 <20160812151745.GA52527@mithlond.kdm.org>
 <CANCZdfq4FLQY3SugEvpMkRCQjhyCHfzFmuqf1m_Mw8LDBoRtLA@mail.gmail.com>
In-Reply-To: <CANCZdfq4FLQY3SugEvpMkRCQjhyCHfzFmuqf1m_Mw8LDBoRtLA@mail.gmail.com>

--srVN6Bwftn190dQEXwoKeebQISJUiN0dC
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 8/12/16 8:21 AM, Warner Losh wrote:
> On Fri, Aug 12, 2016 at 9:17 AM, Kenneth D. Merry <ken@freebsd.org> wro=
te:
>> On Fri, Aug 12, 2016 at 09:13:58 -0600, Warner Losh wrote:
>>> On Fri, Aug 12, 2016 at 9:11 AM, Kenneth D. Merry <ken@freebsd.org> w=
rote:
>>>> On Fri, Aug 12, 2016 at 13:38:21 +0300, Andrey V. Elsukov wrote:
>>>>> On 12.08.16 03:26, Bryan Drewery wrote:
>>>>>> On r303467 I ran into this:
>>>>>>
>>>>>> panic @ time 1470916206.652, thread 0xfffff8000412f000:
>>>>>> g_resize_provider_event but withered
>>>>>> cpuid =3D 0
>>>>>> Panic occurred in module kernel loaded at 0xffffffff80200000:
>>>>>>
>>>>>> Stack: --------------------------------------------------
>>>>>> kernel:kassert_panic+0x166
>>>>>> kernel:g_resize_provider_event+0x181
>>>>>> kernel:g_run_events+0x186^M^M
>>>>>> kernel:fork_exit+0x83^M^M
>>>>>> --------------------------------------------------
>>>>>>
>>>>>> No further information available unfortunately.
>>>>>
>>>>> This one is related to r302087 :)
>>>>
>>>> It looks like there is a race.  I think we need to replace the KASSE=
RT
>>>> in g_resize_provider_event() with a return in case the provider is
>>>> withered.
>>>>
>>>> I won't be able to work on or test this until sometime next week.  S=
o if
>>>> you guys want to go ahead and make the change, please do.
>>>
>>> But why are we calling g_resize_provider on a withered object? That's=

>>> the part I don't understand in this thread.
>>
>> It isn't withered when the event is queued, but it is withered by the =
time
>> the event is executed.
>>
>> There is a check in g_resize_provider() to make sure it isn't withered=
=2E  If
>> not, the event is queued.  But once g_resize_provider_event() runs, it=
 is
>> withered and we run into the KASSERT.
>>
>> There isn't adequate locking and ordering in there to prevent the race=

>> from happening, so the assert should be replaced with an "if (withered=
)
>> return" statement.
>=20
> I'll grant that we may wither with outstanding events, but why is it
> withering? That seems odd. Either we're bogusly posting this event
> just before it will wither, or something else is bogusly withering it.
> Just removing the assert isn't going to fix the underlying issue.
>=20
> Back to Bryan: just to be clear, this is with the latest version of
> the code, and not the intermediate version that was fixed after
> numerous problems surfaced, right?
>=20

No, I was missing r303637.  Hard to say if it is related... Andrey says
it's not.  I haven't dived into it yet and it's so far only happened
once (out of a few tests).  We do have various customizations but I'm
inclined to think it's the stock code having problems.


--=20
Regards,
Bryan Drewery


--srVN6Bwftn190dQEXwoKeebQISJUiN0dC--

--cUcpUOGMI3scLeW38BQE1FqfCJfLSM1TH
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJXreoAAAoJEDXXcbtuRpfPivgIAJPcWlrUrEp21ocPeeIpFiWL
OWx/And4RE/SOtH9+355Bf30mQnSJUQKxZM7Wo/PNfXhVmkaqbLaiJcu+3C4FTJL
VUXpuP1CEzuzpveWbhYy2b4aHa8ape47qBnVjjnNe+cFtPXKeOge6Ymscu9NbHJf
0xSUgMx/3xexOHpVAnUrEHzhNsP3f8yKN6HJN5GF0Sq7SkpG7n35b3u7oEuSDn4z
KYzZ8x2qjo8p6VMkMds+fHaS5Dn73EYPXYpRfEtRJdo3+ZcJFTyZQp8EvjQf+mMY
eoMoBc5a1vcx0hcsxMB7XX6+2RWUuewLgJDdjRObr2RMy/yHA0XEEGnlgewfYDE=
=DYMe
-----END PGP SIGNATURE-----

--cUcpUOGMI3scLeW38BQE1FqfCJfLSM1TH--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?df6da7f2-ffc2-daca-aff5-0fd75fd6e83f>