linux-kernel - Re: [PATCH v2] [media] vb2: include lengths in dmabuf qbuf debug message

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 20 Jul 2016 19:23:06 -0400
From:	Javier Martinez Canillas <javier@....samsung.com>
To:	Sakari Ailus <sakari.ailus@....fi>
Cc:	linux-kernel@...r.kernel.org,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Mauro Carvalho Chehab <mchehab@...pensource.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Pawel Osciak <pawel@...iak.com>, linux-media@...r.kernel.org
Subject: Re: [PATCH v2] [media] vb2: include lengths in dmabuf qbuf debug
 message

Hello Sakari,

On 07/20/2016 07:08 PM, Sakari Ailus wrote:
> Hi Javier,
> 
> On Wed, Jul 20, 2016 at 06:56:52PM -0400, Javier Martinez Canillas wrote:
>> Hello Sakari,
>>
>> On 07/20/2016 03:52 PM, Sakari Ailus wrote:
>>> On Wed, Jul 20, 2016 at 12:07:55PM -0400, Javier Martinez Canillas wrote:
>>>> If the VIDIOC_QBUF ioctl fails due a wrong dmabuf length, it's
>>>> useful to get the invalid and minimum lengths as a debug info.
>>>>
>>>> Before this patch:
>>>>
>>>> vb2-core: __qbuf_dmabuf: invalid dmabuf length for plane 1
>>>>
>>>> After this patch:
>>>>
>>>> vb2-core: __qbuf_dmabuf: invalid dmabuf length 221248 for plane 1, minimum length 410880
>>>>
>>>> Signed-off-by: Javier Martinez Canillas <javier@....samsung.com>
>>>>
>>>> ---
>>>>
>>>> Changes in v2:
>>>> - Use %u instead of %d (Sakari Ailus)
>>>> - Include min_length (Sakari Ailus)
>>>>
>>>>  drivers/media/v4l2-core/videobuf2-core.c | 6 ++++--
>>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c
>>>> index b6fbc04f9699..bbba50d6e1ad 100644
>>>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>>>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>>>> @@ -1227,8 +1227,10 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const void *pb)
>>>>  			planes[plane].length = dbuf->size;
>>>>  
>>>>  		if (planes[plane].length < vb->planes[plane].min_length) {
>>>> -			dprintk(1, "invalid dmabuf length for plane %d\n",
>>>> -				plane);
>>>> +			dprintk(1, "invalid dmabuf length %u for plane %d, "
>>>> +				"minimum length %u\n",
>>>
>>> You shouldn't split strings. It breaks grep.
>>>
>>
>> Yes I know but if I didn't split the line, it would had been longer than
>> the max 80 character per line convention. On those situations I follow
>> what's already done in the file for consistency and most strings in the
>> videobuf2-core file, whose lines are over 80 characters, are being split.
>>
>> But if having a longer line is preferred, I'll happily re-spin the patch.
> 
> I guess in videobuf2's case it's that the strings contain lots of format
> specifiers --- it's not that useful to be able to grep those. I think this
> case is a borderline one.
>

Yes, lots of format specifiers as you said. Which also makes harder to grep
the messages verbatim and someone would had to grep a sub-string anyways or
figure the specifier for each variable to be able to grep the complete line.

So I would prefer to kept the line split as is if you don't mind.
 
> Up to you. You've got my ack.
>

Thanks a lot.
 
>>> With that changed,
>>>
>>> Acked-by: Sakari Ailus <sakari.ailus@...ux.intel.com>
>>>
>>>> +				planes[plane].length, plane,
>>>> +				vb->planes[plane].min_length);
>>>>  			dma_buf_put(dbuf);
>>>>  			ret = -EINVAL;
>>>>  			goto err;
>>>
>>
>> Best regards,
>> -- 
>> Javier Martinez Canillas
>> Open Source Group
>> Samsung Research America
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America