In the majority of cases the read queue for a DCB is handled without locking. This is reasonable, based on the fact that the system will only ever have a single thread processing a DCB in read mode, and such non-locking access is fundamental to the system design and its performances.

However, the use of the function poll_add_epollin_event_to_dcb() does not conform to this principle. It employs a spinlock, but this will only be effective against other uses of the same function, because other types of access to dcb_readqueue do not use a spinlock.

While it would be possible to add spinlocks in all cases, this would have an undesirable impact on performance. The mechanisms around poll_add_epollin_event_to_dcb therefore need to be reviewed to see whether a non-locking resolution can be found.