On 3/17/21 12:55 AM, Avri Altman wrote:

quoted

On 2021-03-16 17:21, Avri Altman wrote:

[ ... ]

quoted

quoted

quoted

And, which lock is protecting rgn->list_expired_rgn? If two
read_to_handler works
are running in parallel, one can be inserting it to its expired_list
while another
can be deleting it.

The timeout handler, being a delayed work, is meant to run every
polling period.
Originally, I had it protected from 2 handlers running concurrently,
But I removed it following Daejun's comment, which I accepted,
Since it is always scheduled using the same polling period.

But one can set the delay to 0 through sysfs, right?

Will restore the protection.  Thanks.

(replying to an email from 2.5 months ago)

Hi Can,

How can two read_to_handler works run in parallel? How can it make a
difference whether or not the delay can be set to zero? Are you aware
that since kernel v3.7 (released in 2012) all workqueues are
non-reentrant? See also commit dbf2576e37da ("workqueue: make all
workqueues non-reentrant"). From the description of that commit:

    This patch makes all workqueues non-reentrant.  If a work item is
    executing on a different CPU when queueing is requested, it is
    always queued to that CPU.  This guarantees that any given work item
    can be executing on one CPU at maximum and if a work item is queued
    and executing, both are on the same CPU.

Thanks,

Bart.