when undeferring a packet, try to timeout_del first to check if you

actually removed it from the timeout wheel before releasing it. if
timeout_del returns 0 then you know the timeout is about to run or
is already running, meaning it will free itself so you dont have
to.

this handling is only done for the undefer paths at SOFTNET since
it is higher than SOFTCLOCK which timeouts run from. it is possible
for a timeout to start running at softclock and get interrupted by
softnet. the undefer in process context blocks both these interrupts
while it undefers, so it is impossible for the timeout to run and
cause the list to be in this inconsistent state.

0 files changed, 0 insertions, 0 deletions