On Tue, Aug 02, 2016 at 09:42:07PM -0700, Rodrigo Vivi wrote:
> A read(fd, buf, len) function should return the number
> of bytes read. In our case we need to return the
> number of bytes we copy to user, instead of returning
> the number of bytes we read internally.
>
> It was really strange when I saw i-g-t test case using
> len '54' but getting '56' as return. First thought was
> how do we read more than we asked? But also I checked
> and there was really only 54. Until I realized it
> was all our fault. EFAULT!
>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index 7052c47..b7b8d79 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3659,7 +3659,7 @@ i915_pipe_crc_read(struct file *filep, char __user *user_buf, size_t count,
>
> spin_unlock_irq(&pipe_crc->lock);
>
> - return bytes_read;
> + return PIPE_CRC_LINE_LEN;
This will no loose entries if you have more than 1 crc ready to be read. I
think better to WARN_ON if snprintf doesn't give us the expected length,
and then correct bytes_read to match.
-Daniel
> }
>
> static const struct file_operations i915_pipe_crc_fops = {
> --
> 2.5.5
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
