Hopefully, it fixes this valgrind warning I just got:
==17120== Thread 13:
==17120== Conditional jump or move depends on uninitialised value(s)
==17120== at 0x6886A15: svc_vc_recv (svc_vc.c:745)
==17120== by 0x6883573: svc_rqst_xprt_task (svc_rqst.c:683)
==17120== by 0x68839F3: svc_rqst_epoll_events (svc_rqst.c:856)
==17120== by 0x6883B43: svc_rqst_epoll_loop (svc_rqst.c:907)
==17120== by 0x6883C15: svc_rqst_run_task (svc_rqst.c:945)
==17120== by 0x688CC2B: work_pool_thread (work_pool.c:197)
==17120== by 0x6441DC4: start_thread (pthread_create.c:308)
==17120== by 0x6DB673C: clone (clone.S:113)
On Fri, Sep 1, 2017 at 6:56 PM, Daniel Gryniewicz <d...@redhat.com> wrote:
> On 09/01/2017 07:09 AM, William Allen Simpson wrote:
>
>> On 8/30/17 1:34 PM, William Allen Simpson wrote:
>>
>>> On 8/28/17 1:23 AM, Frank Filz wrote:
>>>
>>>> WRT14 is the test that failed that made me kick Bill’s patch out of
>>>> dev.5, then I couldn’t get it to fail again, so I included the patch in
>>>> dev.6.
>>>>
>>>> Since it turned out not to be a dev.5 issue. Malahal is reporting
>>> dev.3.
>>>
>>> We should start a new thread, as this isn't about dev.6.
>>>
>>>
>>> I think there is something that is timing sensitive that is exposed, and
>>>> maybe c291141 is the trigger.
>>>>
>>>> I need someone who can reliably re-create to dive into it… Maybe that
>>>> will be me this week…
>>>>
>>>> Malahal says he's able to reliably reproduce on GPFS, was going to
>>> test VFS too.
>>>
>>> He also was going to send us his config, but we haven't seen that yet.
>>>
>>
>> DanG was able to reproduce. Turns out the key was not using loopback to
>> test; required sending over an actual network to induce the timing. Then
>> logging worked.
>>
>> It only occurs where WRT14 sends a minimal 4 byte XDR fragment after a
>> series of long ones, and the TCP segmentation happens to align.
>>
>> Although I'm not yet able to reproduce myself, the problem was obvious
>> walking through the code. An accidental line deletion (setting a local
>> flags variable) in 1 of 3 paths. (That line was present in earlier
>> versions.) Because it is set properly in the most common path, the
>> compiler didn't give an uninitialized warning.
>>
>> Hopefully DanG will be able to verify, and we'll get it in today!
>>
>
> I've verified the fix.
>
> 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
