lkml.org 
[lkml]   [2022]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] net: sched: fix potential null pointer deref
Date
Thanks for your advice and sorry for the noise.

> All netdev devices have their dev->_tx allocated in netif_alloc_netdev_queues()
>
> There is absolutely no way MQ qdisc could be attached to a device that
> has failed netif_alloc_netdev_queues() step.

I believe this makes sense. But I am still a bit confused, especially after we
cross-checked the similar context of mq, mqprio, taprio. To be specific, we
cross-checked whether `mq_class_ops`, `mqprio_class_ops`, and
`taprio_class_ops` check the return value of their respective version of
`_queue_get` before dereferencing it.

--------------- ----- --------- ---------
class_ops whether check the ret value of _queue_get
mq | mqprio | taprio
--------------- ----- --------- ---------
select_queue - - -
graft no yes yes
leaf no yes yes
find yes - yes
walk - - -
dump no no no
dump_stats no no no
--------------- ----- --------- ---------

As shown in this table, `mq_leaf()` does not check the return value of
`mq__queue_get()` before using the pointer, while `mqprio_leaf()` and
`taprio_leaf()` do have such a NULL check.

FYI, here is the code of `mqprio_leaf()` and we can find the NULL check.
```
//net/sched/sch_mqprio.c
static struct Qdisc *mqprio_leaf(struct Qdisc *sch, unsigned long cl)
{
struct netdev_queue *dev_queue = mqprio_queue_get(sch, cl);

if (!dev_queue)
return NULL;

return dev_queue->qdisc_sleeping;
}
```

That is also the situation of `mq_graft()`, `mqprio_graft()` and `taprio_graft()`.
I am not sure whether it is reasonable to expect the class_ops of mq, mqprio,
and taprio to be consistent in this way. If so, does it mean that it is possible
that`mq_leaf()`and `mq_graft` may miss a check here, or mqprio, taprio have
redundant checks?

Thanks again for your time. I apologize if my question is stupid.
\
 
 \ /
  Last update: 2022-06-11 13:03    [W:0.053 / U:0.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site