On Sat, Jan 20, 2018 at 02:11:39PM +0530, Pavan Kondeti wrote: Hi Pavan,
> I have couple questions/comments. > > (1) Since the work is queued on a bounded per-cpu worker, we may run > into a deadlock if a TASKLET is killed from another work running on > the same bounded per-cpu worker. > > For example, > > (1) Schedule a TASKLET on CPU#0 from IRQ. > (2) Another IRQ comes on the same CPU and we queue a work to kill > the TASKLET. > (3) The TASKLET vector is deferred to workqueue. > (4) We run the TASKLET kill work and wait for the TASKLET to finish, > which won't happen. > > We can fix this by queueing the TASKLET kill work on an unbounded > workqueue so that this runs in parallel with TASKLET vector work. > > Just wanted to know if we have to be aware of this *condition*. But IIRC the workqueues have several workers per CPU so the tasklet to be killed can run while the tasklet killer yields. > > (2) Ksoftirqd thread gets parked when a CPU is hotplugged out. So > there is a gaurantee that the softirq handling never happens on > another CPU. Where as a bounded worker gets detached and the queued > work can run on another CPU. I guess, some special handling is > needed to handle hotplug. Good catch. Funny, I worried a bit about CPU hotplug but I assumed the pending CPU-bound worklets would be simply sync'ed before CPU gets down. Breaking their CPU-bound properties doesn't look sane to me. Anyway, I'll need to make a CPU hotplug hook. Thanks for reporting that!
