RTIO Workqueue - Race condition leads to dead-lock in high-demand applications

[ubieda]

Describe the bug

RTIO Workqueue has a race-condition between grabing work items from the pool and giving them back. This was pointed out by @FlorianWeber1018 where he'd run into a crash due to this service not working for submitting I2C transfer requests when stress-testing.

The underlying problem resides in P4WQ not having a way to notify once the item has been freed, as explained here (#84322 (comment)).

There is a fix submitted (#84322 ), in which a callback is used now to properly free the work item before putting it back in the pool.

Expected behavior

There is no race-condition in pool items ownership.

Impact

Apps using RTIO workqueue service are prone to running into this issue. This can result in a dead-lock or a crash assuming the item submitted is never processed.

[ubieda]

Marking as low as it isn't a regression and its in-tree usage is experimental. Please override if you disagree