I think there are two threads, one calling state_unlock() and other calling
state_lock(). The latter doesn't acquire the state_lock leading to the
current crash. My patch is not the culprit. Based on my code reading, the
caller of state_lock() is expected to acquire state_lock if needed. That it
what NFS seems to do.
regards, malahal.
On Thu, Nov 2, 2017 at 9:28 PM, Daniel Gryniewicz <d...@redhat.com> wrote:
> On 11/02/2017 11:46 AM, Frank Filz wrote:
>
>> Ok, so this patch: https://review.gerrithub.io/#/c/385433/ has a real
>> failure visible, however, it clearly has nothing to do with the patch at
>> hand.
>>
>> How do we want to handle that for merge? The patch clearly is ready for
>> merge, but with a -1 Verify, if we're going to make this verification
>> stuff
>> meaningful, we can't proceed.
>>
>> Frank
>>
>>
> It's a use-after-free on the state lock. As such, it may be caused by the
> previous commit in the sequence:
>
> https://review.gerrithub.io/#/c/385104/
>
> Daniel
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
