* [dpdk-dev] Unsafe array accesses in rte_sched.c
@ 2015-10-16 8:49 Simon Kågström
2015-10-16 13:39 ` Dumitrescu, Cristian
0 siblings, 1 reply; 4+ messages in thread
From: Simon Kågström @ 2015-10-16 8:49 UTC (permalink / raw)
To: cristian.dumitrescu, dev
Hi!
I'm investigating DPDK support for pacing output streams and trying to
understand the QoS framework. However, I quickly found some instances of
unsafe array accesses. E.g., the rte_sched_port_config_qsize function
looks like this:
static void
rte_sched_port_config_qsize(struct rte_sched_port *port)
{
/* TC 0 */
port->qsize_add[0] = 0;
port->qsize_add[1] = port->qsize_add[0] + port->qsize[0];
port->qsize_add[2] = port->qsize_add[1] + port->qsize[0];
port->qsize_add[3] = port->qsize_add[2] + port->qsize[0];
[...]
/* TC 3 */
port->qsize_add[12] = port->qsize_add[11] + port->qsize[2];
port->qsize_add[13] = port->qsize_add[12] + port->qsize[3];
port->qsize_add[14] = port->qsize_add[13] + port->qsize[3];
port->qsize_add[15] = port->qsize_add[14] + port->qsize[3];
port->qsize_sum = port->qsize_add[15] + port->qsize[3];
}
but port->qsize is actually defined as
uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
There are similar problems in rte_sched_port_log_pipe_profile() and
probably other places.
I don't understand the code well enough to send patches for these,
although the fixes should be fairly trivial. Perhaps this is already
known as it should be fairly easy to trigger with static checkers?
// Simon
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dpdk-dev] Unsafe array accesses in rte_sched.c
2015-10-16 8:49 [dpdk-dev] Unsafe array accesses in rte_sched.c Simon Kågström
@ 2015-10-16 13:39 ` Dumitrescu, Cristian
2015-10-16 13:50 ` Simon Kågström
0 siblings, 1 reply; 4+ messages in thread
From: Dumitrescu, Cristian @ 2015-10-16 13:39 UTC (permalink / raw)
To: Simon Kågström, dev
> -----Original Message-----
> From: Simon Kågström [mailto:simon.kagstrom@netinsight.net]
> Sent: Friday, October 16, 2015 9:49 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; dev@dpdk.org
> Subject: Unsafe array accesses in rte_sched.c
>
> Hi!
>
> I'm investigating DPDK support for pacing output streams and trying to
> understand the QoS framework. However, I quickly found some instances of
> unsafe array accesses. E.g., the rte_sched_port_config_qsize function
> looks like this:
>
> static void
> rte_sched_port_config_qsize(struct rte_sched_port *port)
> {
> /* TC 0 */
> port->qsize_add[0] = 0;
> port->qsize_add[1] = port->qsize_add[0] + port->qsize[0];
> port->qsize_add[2] = port->qsize_add[1] + port->qsize[0];
> port->qsize_add[3] = port->qsize_add[2] + port->qsize[0];
>
> [...]
>
> /* TC 3 */
> port->qsize_add[12] = port->qsize_add[11] + port->qsize[2];
> port->qsize_add[13] = port->qsize_add[12] + port->qsize[3];
> port->qsize_add[14] = port->qsize_add[13] + port->qsize[3];
> port->qsize_add[15] = port->qsize_add[14] + port->qsize[3];
>
> port->qsize_sum = port->qsize_add[15] + port->qsize[3];
> }
>
> but port->qsize is actually defined as
>
> uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
>
Not sure what you see "unsafe" here: qsize is an array of 4 elements, while qsize_add is a different array of 16 elements? Please explain.
> There are similar problems in rte_sched_port_log_pipe_profile() and
> probably other places.
>
>
> I don't understand the code well enough to send patches for these,
> although the fixes should be fairly trivial. Perhaps this is already
> known as it should be fairly easy to trigger with static checkers?
>
> // Simon
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dpdk-dev] Unsafe array accesses in rte_sched.c
2015-10-16 13:39 ` Dumitrescu, Cristian
@ 2015-10-16 13:50 ` Simon Kågström
2015-10-16 16:10 ` Stephen Hemminger
0 siblings, 1 reply; 4+ messages in thread
From: Simon Kågström @ 2015-10-16 13:50 UTC (permalink / raw)
To: Dumitrescu, Cristian, dev
On 2015-10-16 15:39, Dumitrescu, Cristian wrote:
>> port->qsize_add[12] = port->qsize_add[11] + port->qsize[2];
>> port->qsize_add[13] = port->qsize_add[12] + port->qsize[3];
>> port->qsize_add[14] = port->qsize_add[13] + port->qsize[3];
>> port->qsize_add[15] = port->qsize_add[14] + port->qsize[3];
>>
>> port->qsize_sum = port->qsize_add[15] + port->qsize[3];
>> }
>>
>> but port->qsize is actually defined as
>>
>> uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
>>
>
> Not sure what you see "unsafe" here: qsize is an array of 4 elements, while qsize_add is a different array of 16 elements? Please explain.
Sorry, I should have been more explicit: What I mean that the code
should loop over RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE instead of
hard-coding the numbers.
It certainly works with the current RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE,
but it would be safer (and in my opinion more clear) if it would not
assume RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE == 4.
// Simon
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dpdk-dev] Unsafe array accesses in rte_sched.c
2015-10-16 13:50 ` Simon Kågström
@ 2015-10-16 16:10 ` Stephen Hemminger
0 siblings, 0 replies; 4+ messages in thread
From: Stephen Hemminger @ 2015-10-16 16:10 UTC (permalink / raw)
To: Simon Kågström; +Cc: dev
On Fri, 16 Oct 2015 15:50:55 +0200
Simon Kågström <simon.kagstrom@netinsight.net> wrote:
> On 2015-10-16 15:39, Dumitrescu, Cristian wrote:
> >> port->qsize_add[12] = port->qsize_add[11] + port->qsize[2];
> >> port->qsize_add[13] = port->qsize_add[12] + port->qsize[3];
> >> port->qsize_add[14] = port->qsize_add[13] + port->qsize[3];
> >> port->qsize_add[15] = port->qsize_add[14] + port->qsize[3];
> >>
> >> port->qsize_sum = port->qsize_add[15] + port->qsize[3];
> >> }
> >>
> >> but port->qsize is actually defined as
> >>
> >> uint16_t qsize[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
> >>
> >
> > Not sure what you see "unsafe" here: qsize is an array of 4 elements, while qsize_add is a different array of 16 elements? Please explain.
>
> Sorry, I should have been more explicit: What I mean that the code
> should loop over RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE instead of
> hard-coding the numbers.
>
> It certainly works with the current RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE,
> but it would be safer (and in my opinion more clear) if it would not
> assume RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE == 4.
>
> // Simon
Unfortunately, current code has lots of hard wired assumptions about number
of traffic classes. Lots of manually loop unrolling etc. It would be better
if this was done using loops and telling compiler to unroll critical loops.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-10-16 16:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-16 8:49 [dpdk-dev] Unsafe array accesses in rte_sched.c Simon Kågström
2015-10-16 13:39 ` Dumitrescu, Cristian
2015-10-16 13:50 ` Simon Kågström
2015-10-16 16:10 ` Stephen Hemminger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).