On Tue 2015-07-28 13:18:22, Tejun Heo wrote:
> Hello,
>
> On Tue, Jul 28, 2015 at 04:39:20PM +0200, Petr Mladek wrote:
> > +/*
> > + * Test whether @work is being queued from another work
> > + * executing on the same kthread.
> > + */
> > +static bool is_chained_work(struct kthread_worker *worker)
> > +{
> > + struct kthread_worker *current_worker;
> > +
> > + current_worker = current_kthread_worker();
> > + /*
> > + * Return %true if I'm a kthread worker executing a work item on
> > + * the given @worker.
> > + */
> > + return current_worker && current_worker == worker;
> > +}
>
> I'm not sure full-on chained work detection is necessary here.
> kthread worker's usages tend to be significantly simpler and draining
> is only gonna be used for destruction.
I think that it might be useful to detect bugs when someone
depends on the worker when it is being destroyed. For example,
I tried to convert "khubd" kthread and there was not easy to
double check that this worked as expected.
I actually think about replacing
WARN_ON_ONCE(!is_chained_work(worker)))
with
WARN_ON(!is_chained_work(worker)))
in queue_kthread_work, so that we get the warning for all misused
workers.
> > +void drain_kthread_worker(struct kthread_worker *worker)
> > +{
> > + int flush_cnt = 0;
> > +
> > + spin_lock_irq(&worker->lock);
> > + worker->nr_drainers++;
> > +
> > + while (!list_empty(&worker->work_list)) {
> > + /*
> > + * Unlock, so we could move forward. Note that queuing
> > + * is limited by @nr_drainers > 0.
> > + */
> > + spin_unlock_irq(&worker->lock);
> > +
> > + flush_kthread_worker(worker);
> > +
> > + if (++flush_cnt == 10 ||
> > + (flush_cnt % 100 == 0 && flush_cnt <= 1000))
> > + pr_warn("kthread worker %s: drain_kthread_worker() isn't complete after %u tries\n",
> > + worker->task->comm, flush_cnt);
> > +
> > + spin_lock_irq(&worker->lock);
> > + }
>
> I'd just do something like WARN_ONCE(flush_cnt++ > 10, "kthread worker: ...").
This would print the warning only for one broken worker. But I do not
have strong opinion about it.
Best Regards,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
