Re: [igt-dev] [PATCH i-g-t] lib: Silence Valgrind warning in synce_fence_status

From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, igt-dev@lists.freedesktop.org
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t] lib: Silence Valgrind warning in synce_fence_status
Date: Thu, 27 Jun 2019 14:59:10 +0100	[thread overview]
Message-ID: <73df9149-e9a2-8fc7-ba53-073ca496d5aa@linux.intel.com> (raw)
In-Reply-To: <156164078479.9225.15669406077978719204@skylake-alporthouse-com>

On 27/06/2019 14:06, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-06-27 13:55:21)
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> Let Valgrind know the ioctl initializes the passed in info block to reduce
>> the noise while debugging.
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> ---
>>   lib/sw_sync.c | 11 +++++++++++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/lib/sw_sync.c b/lib/sw_sync.c
>> index f208603312c2..73f3f7015d9d 100644
>> --- a/lib/sw_sync.c
>> +++ b/lib/sw_sync.c
>> @@ -41,6 +41,15 @@
>>   #include "drmtest.h"
>>   #include "ioctl_wrappers.h"
>>   
>> +#ifdef HAVE_VALGRIND
>> +#include <valgrind/valgrind.h>
>> +#include <valgrind/memcheck.h>
>> +
>> +#define VG(x) x
>> +#else
>> +#define VG(x) do {} while (0)
>> +#endif
>> +
>>   /**
>>    * SECTION:sw_sync
>>    * @short_description: Software sync (fencing) support library
>> @@ -218,6 +227,8 @@ int sync_fence_status(int fence)
>>          if (file_info.num_fences != 1)
>>                  return -EINVAL;
> 
> ^ Otherwise known as lets pretend we never saw that kernel bug.
> https://patchwork.freedesktop.org/patch/311883/?series=62278&rev=1
> 
> An example of why igt should not be filtering the kernel.

You think the library helper shouldn't be testing for num_fences == 1, 
eg the same as passed in? It is questionable that it should return 
-EINVAL in this case I agree with that. If that's what you meant with 
filtering.

> Just complaining because Petri found a bug in one of tests that is being
> blocked by no one reviewing the kernel fix that is blocking fixing the
> library to allow the bug fix in the test.

It's only related because it's the same ioctl. :) But...

>> +       VG(VALGRIND_MAKE_MEM_DEFINED(&fence_info, sizeof(fence_info)));
> 
> More fun would be to
> 
> struct sync_fence_info fence_info = { .status = -ENOSYS };
> 
> So that valgrind knows it is initialised and we reliably report an error
> if the kernel fails to fill in the struct.

... sure, this is also okay. For me -ENOSYS is not strictly needed at 
this level. It would be more of a unit test for the ioctl, not belonging 
to the library helper, but it is also fine to inject some more explicit 
trash so it can be caught even if there are no specific unit tests.

I don't also see a problem with Valgrind annotation. It doesn't hide 
anything, nor does it sanitises. But yes, it is not needed if we go for 
-ENOSYS trick.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx