Re: VIVID/VIMC and media fuzzing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/09/2018 10:34 PM, Dmitry Vyukov wrote:
>>> What would be a good improvement is if you add this to the kernel command options:
>>> "vivid.n_devs=2 vivid.multiplanar=1,2"
>>>
>>> This will create two vivid instances, one using the single planar API and one using
>>> the multiplanar API. That will improve the test coverage.
>>
>> Re this and collisions between multiple test processes. We actually
>> would like to have moar devices and partition them between test
>> processes. Say if we need need devices for 8 test processes, will it
>> work to specify something like "vivid.n_devs=16
>> vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2" and then use
>> devices 0/1 in the first test process, 2/3 in the second and so on?
>>
>> Without giving any flags, I see 8 /dev/video* devices, does
>> vivid.n_devs defaults to 8?
> 
> I am a bit lost.
> 
> vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2
> creates 32 /dev/video* devices.

I see 38 /dev/video* devices: the first 3 are from vimc, then 2 * 16 = 32
vivid devices (2 video nodes for each instance), then a vim2m device and
finally two vicodec devices.

So you should always see 6 + n_devs * 2 video devices.

> 
> but vivid.n_devs=8 vivid.multiplanar=1,2,1,2,1,2,1,2 creates 24
> /dev/video* devices.
> 
> These parameters also affect /dev/{vbi,radio,swradio} in strange ways
> 
> Also, by default there is /dev/radio0 and /dev/radio1, are these
> different types of devices, e.g. "source" and "sink"? Or they are
> identical? And the same question for other types of devices?

vivid creates two radio devices per instance: one emulates a radio tuner,
one emulates a radio modulator (so yes, source and sink). Same for vbi
(one source, one sink) and one swradio device. It also creates two cec
devices (source and sink).

> 
> How can I create 8 independent partitions of devices? What devices
> will belong to each partition?

Exactly as you did above. Instance X (starting at 0) uses video nodes
3+2*X and 4+2*X.

> 
> 
>>> I also noticed that you appear to test only video devices. But vivid also creates
>>> vbi, radio and swradio devices. It would be nice to have those tested as well.
>>
>> Will do.
>> FTR, this is these devices:
>>
>> # ls -l /dev/{vbi,radio,swradio}*
>> crw-rw---- 1 root video 81, 14 Nov  9 21:07 /dev/radio0
>> crw-rw---- 1 root video 81, 15 Nov  9 21:07 /dev/radio1
>> crw-rw---- 1 root video 81, 13 Nov  9 21:07 /dev/swradio0
>> crw-rw---- 1 root video 81, 11 Nov  9 21:07 /dev/vbi0
>> crw-rw---- 1 root video 81, 12 Nov  9 21:07 /dev/vbi1
>>
>> Why are there 2 radio and vbi? Are they different? Is it possible to
>> also create more of them? Are there any other useful command line args
>> for them?

As mentioned: the first is capture, the second output. It's per vivid
instance.

<snip>

>>>> CREATE_BUFS privatization is somewhat unfortunate, but I guess we can
>>>> live with it for now.
>>>
>>> Sorry, I'm not sure what you mean.
>>
>> You said:
>>
>>>> But after calling REQBUFS or CREATE_BUFS the filehandle that
>>>> called those ioctls becomes owner of the device until the buffers are
>>>> released. So other filehandles cannot do any streaming operations (EBUSY
>>>> will be returned).
>>
>> This semantics are somewhat unfortunate for syzkaller because one test
>> process will affect/block other test processes, and we try to make
>> them as independent as possible. E.g. If this can affect syzkaller
>> ability to create reproducers, because in one run of a test if was
>> affected by an unrelated test and crashed, but if we try to reproduce
>> the crash on the same test it won't crash again because now it's not
>> affected by the unrelated test.
>>
>> But if we create more devices and partition them across test
>> processes, it will resolve this problem?

I think it will help, yes.

>>
>>
>>>> I assume that when the process dies it will release everything at
>>>> least, because fuzzer will sure not pair create with release all the
>>>> time.




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux