On Fri, 03 Apr 2020 09:17:14 -0700, Chris Wilson wrote: > > Quoting Ashutosh Dixit (2020-04-03 02:01:20) > > It is wrong to block the user thread in the next poll when OA data is > > already available which could not fit in the user buffer provided in > > the previous read. In several cases the exact user buffer size is not > > known. Blocking user space in poll can lead to data loss when the > > buffer size used is smaller than the available data. > > > > This change fixes this issue and allows user space to read all OA data > > even when using a buffer size smaller than the available data using > > multiple non-blocking reads rather than staying blocked in poll till > > the next timer interrupt. > > > > v2: Fix ret value for blocking reads (Umesh) > > v3: Mistake during patch send (Ashutosh) > > v4: Remove -EAGAIN from comment (Umesh) > > v5: Improve condition for clearing pollin and return (Lionel) > > v6: Improve blocking read loop and other cleanups (Lionel) > > v7: Added Cc stable > > > > Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@xxxxxxxxx> > > Cc: <stable@xxxxxxxxxxxxxxx> > > Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@xxxxxxxxx> > > Signed-off-by: Ashutosh Dixit <ashutosh.dixit@xxxxxxxxx> > > Did you manage to devise a test case? It is nice (some might say > important) to pair a patch for stable with its regression test. Yes there is a test case here: https://patchwork.freedesktop.org/series/75100/#rev3 Lionel verified that it is fails on stable kernels here: https://patchwork.freedesktop.org/patch/358873/?series=75100&rev=1 Thanks! -- Ashutosh _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx