svn commit: r303019 - head/sys/geom

[Bryan Drewery]

On 8/12/16 8:21 AM, Warner Losh wrote:
> On Fri, Aug 12, 2016 at 9:17 AM, Kenneth D. Merry <ken at freebsd.org> wrote:
>> 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 at freebsd.org> wrote:
>>>> 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 = 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 KASSERT
>>>> 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.  So 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.  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.
> 
> 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.
> 
> 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?
> 

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.


-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20160812/7a7ab6e7/attachment.sig>