Messages in this thread | | | From | "Jianhao Xu" <> | Subject | Re: [PATCH] net: sched: fix potential null pointer deref | Date | Sat, 11 Jun 2022 13:00:48 +0200 |
| |
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. | |