For the Cyclone Ethernet interrupt my implementer chose a portYIELD on exit after signaling a binary semaphore to a high priority task. Because the portYIELD causes a software interrupt most often, I believe under packet storms that the vTaskSwitchContext() in vPortYieldISR bypasses the 1ms clock that drives the time slicing in our system. The netTask runs far too often and low priority tasks are starved. This scenario appears a Cyclone artifact. Has the vulnerability been addressed? Is this better asked of the Cyclone folk? I apologize in advance if this is either known, or is an inappropriate venue for discussion.
The interrupt should be using xSemaphoreGiveFromISR to signal the binary semaphore. Functions named “FromISR” take an output pointer to a flag indicating whether the scheduler should switch tasks. portYIELD_FROM_ISR accepts this flag.
This is likely a question for Cyclone if their implementation is not doing this.
Indeed their application is doing this. Could you address the vulnerability? Or is that out of scope?
When portYIELD switches contexts, the rest of the current tick is given immediately to the high-priority task. By-design the highest-priority task in FreeRTOS is scheduled to run if it is unblocked.
The only time the highest-priority task will share time with other tasks is when it is blocked, when it yields or delays, or if preemption is enabled and another task shares priority. If the latency of responding to an Ethernet interrupt is less important than not starving tasks, adjusting priorities and enabling task preemption may solve this issue. Adjusting lower-priority tasks up to the netTask has the same effect as lowering the netTask down.
If the Ethernet interrupt must be responded to immediately, then the netTask could have another point where it can block or yield time to other tasks besides waiting on interrupts. Or, it could use decision-making to entirely drop those interrupts.
Which vulnerability are you talking about? Is it our code? Can you share the link to the code you are talking about?
The vulnerability is in Cyclone. The stack runs at Priority 2. Even a flood ping will starve out Priority 1 Tasks. I have tested this. Apologies to taking so long to answer. I did not see your comment. My suggestion is that the default be 1. There is little impact to performance.
Please report this to the authors of that stack. Let us know if you have any other question for FreeRTOS.