* [igt-dev] [PATCH i-g-t] lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd
@ 2019-03-12 11:21 Petri Latvala
2019-03-12 11:34 ` Chris Wilson
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Petri Latvala @ 2019-03-12 11:21 UTC (permalink / raw)
To: igt-dev; +Cc: Petri Latvala
If the ioctl is successful, the returned fd should be valid. Check
that it is, thus also helping static analysis in almost 70 call sites.
Signed-off-by: Petri Latvala <petri.latvala@intel.com>
---
lib/ioctl_wrappers.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 39920f87..31969e77 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1332,6 +1332,7 @@ int prime_handle_to_fd(int fd, uint32_t handle)
args.fd = -1;
do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args);
+ igt_assert_fd(args.fd);
return args.fd;
}
--
2.19.1
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [igt-dev] [PATCH i-g-t] lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd 2019-03-12 11:21 [igt-dev] [PATCH i-g-t] lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd Petri Latvala @ 2019-03-12 11:34 ` Chris Wilson 2019-03-12 13:00 ` Petri Latvala 2019-03-12 12:08 ` [igt-dev] ✗ Fi.CI.BAT: failure for " Patchwork 2019-03-12 15:25 ` [igt-dev] [PATCH i-g-t] " Daniel Vetter 2 siblings, 1 reply; 9+ messages in thread From: Chris Wilson @ 2019-03-12 11:34 UTC (permalink / raw) To: Petri Latvala, igt-dev; +Cc: Petri Latvala Quoting Petri Latvala (2019-03-12 11:21:14) > If the ioctl is successful, the returned fd should be valid. Check > that it is, thus also helping static analysis in almost 70 call sites. > > Signed-off-by: Petri Latvala <petri.latvala@intel.com> > --- > lib/ioctl_wrappers.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c > index 39920f87..31969e77 100644 > --- a/lib/ioctl_wrappers.c > +++ b/lib/ioctl_wrappers.c > @@ -1332,6 +1332,7 @@ int prime_handle_to_fd(int fd, uint32_t handle) > args.fd = -1; > > do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args); > + igt_assert_fd(args.fd); Why? Why would we be using a static analysis tool that complains about feeding invalid data to the kernel, because that is exactly the goal of igt. -Chris _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [igt-dev] [PATCH i-g-t] lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd 2019-03-12 11:34 ` Chris Wilson @ 2019-03-12 13:00 ` Petri Latvala 2019-03-12 13:14 ` Chris Wilson 0 siblings, 1 reply; 9+ messages in thread From: Petri Latvala @ 2019-03-12 13:00 UTC (permalink / raw) To: Chris Wilson; +Cc: igt-dev On Tue, Mar 12, 2019 at 11:34:37AM +0000, Chris Wilson wrote: > Quoting Petri Latvala (2019-03-12 11:21:14) > > If the ioctl is successful, the returned fd should be valid. Check > > that it is, thus also helping static analysis in almost 70 call sites. > > > > Signed-off-by: Petri Latvala <petri.latvala@intel.com> > > --- > > lib/ioctl_wrappers.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c > > index 39920f87..31969e77 100644 > > --- a/lib/ioctl_wrappers.c > > +++ b/lib/ioctl_wrappers.c > > @@ -1332,6 +1332,7 @@ int prime_handle_to_fd(int fd, uint32_t handle) > > args.fd = -1; > > > > do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args); > > + igt_assert_fd(args.fd); > > Why? Why would we be using a static analysis tool that complains about > feeding invalid data to the kernel, because that is exactly the goal of > igt. Because after teaching it what data should be invalid and what should be valid, it has already revealed a couple of bugs? Are you objecting to checking that the ioctl gives an fd that is >= 0? Where's the line here, what parts of the uapi semantics must always be left unchecked in a test suite for uapi? -- Petri Latvala _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [igt-dev] [PATCH i-g-t] lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd 2019-03-12 13:00 ` Petri Latvala @ 2019-03-12 13:14 ` Chris Wilson 2019-03-13 9:20 ` Petri Latvala 0 siblings, 1 reply; 9+ messages in thread From: Chris Wilson @ 2019-03-12 13:14 UTC (permalink / raw) To: Petri Latvala; +Cc: igt-dev Quoting Petri Latvala (2019-03-12 13:00:04) > On Tue, Mar 12, 2019 at 11:34:37AM +0000, Chris Wilson wrote: > > Quoting Petri Latvala (2019-03-12 11:21:14) > > > If the ioctl is successful, the returned fd should be valid. Check > > > that it is, thus also helping static analysis in almost 70 call sites. > > > > > > Signed-off-by: Petri Latvala <petri.latvala@intel.com> > > > --- > > > lib/ioctl_wrappers.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c > > > index 39920f87..31969e77 100644 > > > --- a/lib/ioctl_wrappers.c > > > +++ b/lib/ioctl_wrappers.c > > > @@ -1332,6 +1332,7 @@ int prime_handle_to_fd(int fd, uint32_t handle) > > > args.fd = -1; > > > > > > do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args); > > > + igt_assert_fd(args.fd); > > > > Why? Why would we be using a static analysis tool that complains about > > feeding invalid data to the kernel, because that is exactly the goal of > > igt. > > Because after teaching it what data should be invalid and what should > be valid, it has already revealed a couple of bugs? Did the kernel handle the invalid fd correctly? That is what is important. It's not a bug for igt to call close(-1) or whatever. > Are you objecting to checking that the ioctl gives an fd that is >= 0? > Where's the line here, what parts of the uapi semantics must always be > left unchecked in a test suite for uapi? No, my opinion is htat this assertion is only valid in a test not library code, as the library code should just be a conduit and even the do_ioctl is a mistake as there is no higher level wrapper here. -Chris _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [igt-dev] [PATCH i-g-t] lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd 2019-03-12 13:14 ` Chris Wilson @ 2019-03-13 9:20 ` Petri Latvala 0 siblings, 0 replies; 9+ messages in thread From: Petri Latvala @ 2019-03-13 9:20 UTC (permalink / raw) To: Chris Wilson; +Cc: igt-dev On Tue, Mar 12, 2019 at 01:14:17PM +0000, Chris Wilson wrote: > Quoting Petri Latvala (2019-03-12 13:00:04) > > On Tue, Mar 12, 2019 at 11:34:37AM +0000, Chris Wilson wrote: > > > Quoting Petri Latvala (2019-03-12 11:21:14) > > > > If the ioctl is successful, the returned fd should be valid. Check > > > > that it is, thus also helping static analysis in almost 70 call sites. > > > > > > > > Signed-off-by: Petri Latvala <petri.latvala@intel.com> > > > > --- > > > > lib/ioctl_wrappers.c | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c > > > > index 39920f87..31969e77 100644 > > > > --- a/lib/ioctl_wrappers.c > > > > +++ b/lib/ioctl_wrappers.c > > > > @@ -1332,6 +1332,7 @@ int prime_handle_to_fd(int fd, uint32_t handle) > > > > args.fd = -1; > > > > > > > > do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args); > > > > + igt_assert_fd(args.fd); > > > > > > Why? Why would we be using a static analysis tool that complains about > > > feeding invalid data to the kernel, because that is exactly the goal of > > > igt. > > > > Because after teaching it what data should be invalid and what should > > be valid, it has already revealed a couple of bugs? > > Did the kernel handle the invalid fd correctly? That is what is > important. It's not a bug for igt to call close(-1) or whatever. But it is a bug in IGT if you call a function foo() and expect it to do error handling for you, and it giving you stuff you'd still need to check yourself. Imagine PRIME_HANDLE_TO_FD ioctl being broken and giving out fd -5. It would show up in test results, but pointing to further ioctls failing with EINVAL. > > Are you objecting to checking that the ioctl gives an fd that is >= 0? > > Where's the line here, what parts of the uapi semantics must always be > > left unchecked in a test suite for uapi? > > No, my opinion is htat this assertion is only valid in a test not library > code, as the library code should just be a conduit and even the do_ioctl > is a mistake as there is no higher level wrapper here. Is that tested in a test currently, I didn't search thoroughly? All call sites I checked just use the returned fd as it was valid. Library code should just be a conduit, sure. But it's also a valid expectation that functions that are supposed to automatically fail/skip for you on errors do them for all occasions that can cause the library code to fail their postcondition of valid data. It's the whole reason we have functions typically in pairs of foo() and __foo(). How do we go forward? 1) Splash in an __prime_handle_to_fd() that will return the fd directly, make prime_handle_to_fd call that and assert that the ioctl succeeded and the fd is >= 0 2) Use igt_assume() instead for the fd, point to a test that checks the validness of the fd on a successful ioctl in the commit message -- Petri Latvala _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 9+ messages in thread
* [igt-dev] ✗ Fi.CI.BAT: failure for lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd 2019-03-12 11:21 [igt-dev] [PATCH i-g-t] lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd Petri Latvala 2019-03-12 11:34 ` Chris Wilson @ 2019-03-12 12:08 ` Patchwork 2019-03-12 15:25 ` [igt-dev] [PATCH i-g-t] " Daniel Vetter 2 siblings, 0 replies; 9+ messages in thread From: Patchwork @ 2019-03-12 12:08 UTC (permalink / raw) To: Petri Latvala; +Cc: igt-dev == Series Details == Series: lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd URL : https://patchwork.freedesktop.org/series/57873/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5735 -> IGTPW_2594 ==================================================== Summary ------- **FAILURE** Serious unknown changes coming with IGTPW_2594 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in IGTPW_2594, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/57873/revisions/1/mbox/ Possible new issues ------------------- Here are the unknown changes that may have been introduced in IGTPW_2594: ### IGT changes ### #### Possible regressions #### * igt@i915_selftest@live_hangcheck: - fi-cfl-8700k: PASS -> DMESG-FAIL Known issues ------------ Here are the changes found in IGTPW_2594 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_exec_basic@gtt-bsd2: - fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] +57 * igt@i915_module_load@reload: - fi-blb-e6850: NOTRUN -> INCOMPLETE [fdo#107718] * igt@i915_selftest@live_evict: - fi-bsw-kefka: PASS -> DMESG-WARN [fdo#107709] * igt@kms_addfb_basic@addfb25-y-tiled-small: - fi-byt-n2820: NOTRUN -> SKIP [fdo#109271] +56 * igt@kms_busy@basic-flip-a: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1 * igt@kms_busy@basic-flip-c: - fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-byt-n2820: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_chamelium@hdmi-crc-fast: - fi-bsw-n3050: NOTRUN -> SKIP [fdo#109271] +62 * igt@kms_chamelium@hdmi-edid-read: - fi-hsw-peppy: NOTRUN -> SKIP [fdo#109271] +46 * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: NOTRUN -> DMESG-FAIL [fdo#102614] / [fdo#107814] - fi-byt-clapper: NOTRUN -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: NOTRUN -> FAIL [fdo#103191] / [fdo#107362] * igt@kms_psr@primary_mmap_gtt: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +8 * igt@runner@aborted: - fi-bsw-kefka: NOTRUN -> FAIL [fdo#107709] #### Possible fixes #### * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: FAIL [fdo#108511] -> PASS * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: FAIL [fdo#103167] -> PASS * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@prime_vgem@basic-fence-flip: - fi-gdg-551: DMESG-FAIL [fdo#103182] -> PASS - fi-kbl-7567u: FAIL [fdo#104008] -> PASS [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182 [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 [fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107814]: https://bugs.freedesktop.org/show_bug.cgi?id=107814 [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 Participating hosts (41 -> 40) ------------------------------ Additional (4): fi-hsw-peppy fi-byt-n2820 fi-byt-clapper fi-bsw-n3050 Missing (5): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-bdw-samus Build changes ------------- * IGT: IGT_4881 -> IGTPW_2594 CI_DRM_5735: a51930d5783a7de342db8ea03199fcc0ab31c098 @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_2594: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2594/ IGT_4881: 6ef8aa586de6ea899dd567378ba0f76885bdd914 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2594/ _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [igt-dev] [PATCH i-g-t] lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd 2019-03-12 11:21 [igt-dev] [PATCH i-g-t] lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd Petri Latvala 2019-03-12 11:34 ` Chris Wilson 2019-03-12 12:08 ` [igt-dev] ✗ Fi.CI.BAT: failure for " Patchwork @ 2019-03-12 15:25 ` Daniel Vetter 2019-03-13 8:59 ` Petri Latvala 2 siblings, 1 reply; 9+ messages in thread From: Daniel Vetter @ 2019-03-12 15:25 UTC (permalink / raw) To: Petri Latvala; +Cc: igt-dev On Tue, Mar 12, 2019 at 01:21:14PM +0200, Petri Latvala wrote: > If the ioctl is successful, the returned fd should be valid. Check > that it is, thus also helping static analysis in almost 70 call sites. > > Signed-off-by: Petri Latvala <petri.latvala@intel.com> > --- > lib/ioctl_wrappers.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c > index 39920f87..31969e77 100644 > --- a/lib/ioctl_wrappers.c > +++ b/lib/ioctl_wrappers.c > @@ -1332,6 +1332,7 @@ int prime_handle_to_fd(int fd, uint32_t handle) > args.fd = -1; > > do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args); > + igt_assert_fd(args.fd); fd >= 0 if we want this check. I think it's ok to have the assert here, since do_ioctl already checks that the ioctl didn't fail. If we want an unchecked version we can add the usual __prime_hanlde_to_fd. -Daniel > > return args.fd; > } > -- > 2.19.1 > > _______________________________________________ > igt-dev mailing list > igt-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/igt-dev -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [igt-dev] [PATCH i-g-t] lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd 2019-03-12 15:25 ` [igt-dev] [PATCH i-g-t] " Daniel Vetter @ 2019-03-13 8:59 ` Petri Latvala 2019-03-13 13:18 ` Daniel Vetter 0 siblings, 1 reply; 9+ messages in thread From: Petri Latvala @ 2019-03-13 8:59 UTC (permalink / raw) To: Daniel Vetter; +Cc: igt-dev On Tue, Mar 12, 2019 at 04:25:33PM +0100, Daniel Vetter wrote: > On Tue, Mar 12, 2019 at 01:21:14PM +0200, Petri Latvala wrote: > > If the ioctl is successful, the returned fd should be valid. Check > > that it is, thus also helping static analysis in almost 70 call sites. > > > > Signed-off-by: Petri Latvala <petri.latvala@intel.com> > > --- > > lib/ioctl_wrappers.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c > > index 39920f87..31969e77 100644 > > --- a/lib/ioctl_wrappers.c > > +++ b/lib/ioctl_wrappers.c > > @@ -1332,6 +1332,7 @@ int prime_handle_to_fd(int fd, uint32_t handle) > > args.fd = -1; > > > > do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args); > > + igt_assert_fd(args.fd); > > fd >= 0 if we want this check. I think it's ok to have the assert here, since > do_ioctl already checks that the ioctl didn't fail. If we want an > unchecked version we can add the usual __prime_hanlde_to_fd. fd >= 0 is what igt_assert_fd does? -- Petri Latvala _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [igt-dev] [PATCH i-g-t] lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd 2019-03-13 8:59 ` Petri Latvala @ 2019-03-13 13:18 ` Daniel Vetter 0 siblings, 0 replies; 9+ messages in thread From: Daniel Vetter @ 2019-03-13 13:18 UTC (permalink / raw) To: Daniel Vetter, igt-dev On Wed, Mar 13, 2019 at 10:59:09AM +0200, Petri Latvala wrote: > On Tue, Mar 12, 2019 at 04:25:33PM +0100, Daniel Vetter wrote: > > On Tue, Mar 12, 2019 at 01:21:14PM +0200, Petri Latvala wrote: > > > If the ioctl is successful, the returned fd should be valid. Check > > > that it is, thus also helping static analysis in almost 70 call sites. > > > > > > Signed-off-by: Petri Latvala <petri.latvala@intel.com> > > > --- > > > lib/ioctl_wrappers.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c > > > index 39920f87..31969e77 100644 > > > --- a/lib/ioctl_wrappers.c > > > +++ b/lib/ioctl_wrappers.c > > > @@ -1332,6 +1332,7 @@ int prime_handle_to_fd(int fd, uint32_t handle) > > > args.fd = -1; > > > > > > do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args); > > > + igt_assert_fd(args.fd); > > > > fd >= 0 if we want this check. I think it's ok to have the assert here, since > > do_ioctl already checks that the ioctl didn't fail. If we want an > > unchecked version we can add the usual __prime_hanlde_to_fd. > > fd >= 0 is what igt_assert_fd does? I'm blind :-/ -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-03-13 13:18 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-03-12 11:21 [igt-dev] [PATCH i-g-t] lib/ioctl_wrappers: Assert that prime_handle_to_fd returns a valid fd Petri Latvala 2019-03-12 11:34 ` Chris Wilson 2019-03-12 13:00 ` Petri Latvala 2019-03-12 13:14 ` Chris Wilson 2019-03-13 9:20 ` Petri Latvala 2019-03-12 12:08 ` [igt-dev] ✗ Fi.CI.BAT: failure for " Patchwork 2019-03-12 15:25 ` [igt-dev] [PATCH i-g-t] " Daniel Vetter 2019-03-13 8:59 ` Petri Latvala 2019-03-13 13:18 ` Daniel Vetter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox