Hi Jon,

On Sat, Aug 25, 2012 at 2:30 PM, Jonathan Corbet [off-list ref] wrote:

On Sat, 25 Aug 2012 13:12:01 -0300
Ezequiel Garcia [off-list ref] wrote:

quoted

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.