On 11/10/2018 08:28 PM, Dmitry Vyukov wrote:
> On Sat, Nov 10, 2018 at 2:01 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
>> 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.
>
> Thanks! Now I got it.
> I've extended syzkaller to create more devices, use planar/non-planar,
> radio, swradio, cec, vbi:
>
> https://github.com/google/syzkaller/commit/f3c4e6185953baea53d5651b84bd5897c02627f4#diff-a6fc2c4d3df5a6bcb42a628db614175f
>
> https://github.com/google/syzkaller/commit/f3c4e6185953baea53d5651b84bd5897c02627f4#diff-c60ec5d4add9b876f5d28fdeeaf3b7b8
The cec devices do not use the V4L2 API, so it might be premature to add those.
I plan on providing a patch for CEC in the near (?) future. Do you happen to
have a script or something that can convert an API header to something that
syzkaller needs? Or is it all manual?
Regards,
Hans
>
>
>>>>> 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.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "syzkaller" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@xxxxxxxxxxxxxxxx.
>> For more options, visit https://groups.google.com/d/optout.
