Re: [PATCH] atkbd: cancel delayed work before freeing its structure

[Oleg Nesterov]

On 11/11, Dmitry Torokhov wrote:
>
> On Tue, Nov 11, 2008 at 06:20:50PM +0100, Oleg Nesterov wrote:
> > On 11/11, Dmitry Torokhov wrote:
> > >
> > But let me repeat, if queue_delayed_work() fails becuase this work is
> > already queued we (in this particular case) need mb(), not wmb(). Or
> > atkbd_schedule_event_work() can miss a bit in ->event_mask. So I think
> > this wmb() is misleading.
>
> Could you please explain why wmb() is not enough and full mb() is
> needed in this case? I thought that if write happens before we decide
> whether to schedule event_work or not it would be enough.

Yes, but how we decide whether to schedule or not? Let's suppose we do
this without mb(). say, queue_work() starts with

	if (test_bit(WORK_STRUCT_PENDING)) // no barrier semantics
		return;

In that case the code in atkbd_schedule_event_work()

	set_bit(event_bit, &atkbd->event_mask);
	wmb();
	schedule_delayed_work(atkbd->event_work);

can be reordered (if ->event_work is queued) as

	schedule_delayed_work(atkbd->event_work);
	set_bit(event_bit, &atkbd->event_mask);

wmb() can only serialize STOREs, not STORE vs LOAD. The result of
set_bit() can be "delayed".

Now, run_workqueue() does

	// again, no barrier semantics, but this doesn't matter
	clear_bit(WORK_STRUCT_PENDING);

	call atkbd_schedule_event_work()
		if (test_and_clear_bit(atkbd->event_mask))
			 atkbd_set_xxx();

and we can miss an event.

> > And unneeded because queue_work() implies mb(),
> > but this is not really documented.
>
> It would be great if we can get it documented and then i'd drop *mb()
> from atkbd.

It is not easy document the current behaviour. Actually, perhaps
run_workqueue() needs smp_mb__after_clear_bit()...

But for this particular case this doesn't matter. Note that
atkbd_event_work() does test_and_clear_bit(), it can't be re-ordered
with clear_bit(WORK_STRUCT_PENDING), otherwise even mb() can't help.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/