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
>>>> 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.
