Hi Jon,
On Sat, Aug 25, 2012 at 2:30 PM, Jonathan Corbet <corbet@xxxxxxx> wrote:
> On Sat, 25 Aug 2012 13:12:01 -0300
> Ezequiel Garcia <elezegarcia@xxxxxxxxx> wrote:
>
>> The mentioned BUG_ON() are these:
>>
>> void vb2_queue_init(struct vb2_queue *q)
>> {
>> BUG_ON(!q);
>> BUG_ON(!q->ops);
>> BUG_ON(!q->mem_ops);
>> BUG_ON(!q->type);
>> BUG_ON(!q->io_modes);
>> [...]
>>
>> Unless I'm overlooking something they look fine to me,
>> since vb2_queue should always be prepared by the driver.
>
> http://permalink.gmane.org/gmane.linux.kernel/1347333 is, I believe, the
> definitive word on this kind of use of BUG_ON()...
>
As usual Linus's words are truly enlightening.
Perhaps you could help me understand this better:
1.
Why do we need to check for all these conditions in the first place?
There are many other functions relying on "struct vb2_queue *q"
not being null (almost all of them) and we don't check for it.
What makes vb2_queue_init() so special that we need to check for it?
2.
If a DoS attack is the concern here, I wonder how this would be achieved?
vb2_queue_init() is an "internal" (so to speak) function, that will only
be called by videobuf2 drivers.
I'm not arguing, truly. I wan't to understand what's the rationale behind
putting BUG_ON, or WARN_ON, or return -EINVAL in a case like this.
Thanks,
Ezequiel.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
