On 4/15/2022 5:29 AM, Jakob Koschel wrote:
To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.
To *never* use the list iterator variable after the loop it was
concluded to use a sep
On 4/15/2022 5:29 AM, Jakob Koschel wrote:
From: Vladimir Oltean
We know that "dev > dst->last_switch" in the "else" block.
In other words, that "dev - dst->last_switch" is > 0.
dsa_port_bridge_num_get(dp) can be 0, but the check
"if (bridge_num + dst->last_switch != dev) continue", rewritt
On 4/15/2022 5:29 AM, Jakob Koschel wrote:
From: Vladimir Oltean
To avoid bugs and speculative execution exploits due to type-confused
pointers at the end of a list_for_each_entry() loop, one measure is to
restrict code to not use the iterator variable outside the loop block.
In the case of
On 4/15/2022 5:29 AM, Jakob Koschel wrote:
From: Vladimir Oltean
When passed a non-head list element, list_add_tail() actually adds the
new element to its left, which is what we want. Despite the slightly
confusing name, use the dedicated function which does the same thing as
the open-coded
On 4/15/2022 5:29 AM, Jakob Koschel wrote:
From: Vladimir Oltean
sja1105_first_entry_longer_than() does not make use of the full struct
sja1105_gate_entry *e, just of e->interval which is set from the passed
entry_time.
This means that if there is a gate conflict, we have allocated e for
no
On 4/15/2022 5:29 AM, Jakob Koschel wrote:
From: Vladimir Oltean
The link below explains that there is a desire to syntactically change
list_for_each_entry() and list_for_each() such that it becomes
impossible to use the iterator variable outside the scope of the loop.
Although sja1105_inse
