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

From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	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 15:06:35 +0100	[thread overview]
Message-ID: <156164439534.9225.10573719047261245304@skylake-alporthouse-com> (raw)
In-Reply-To: <73df9149-e9a2-8fc7-ba53-073ca496d5aa@linux.intel.com>

Quoting Tvrtko Ursulin (2019-06-27 14:59:10)
> 
> On 27/06/2019 14:06, Chris Wilson wrote:
> >> +       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.

That's all I was thinking, two birds one stone. I think it is a bonus if
we don't paper over the kernel randomly serving up garbage -- but at the
same time random failures are not the easiest to debug. But at least they
serve as canaries.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx