All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Jiri Pirko <jpirko@redhat.com>,
	linux-kernel@vger.kernel.org, linux-input@vger.kernel.org
Subject: Re: [PATCH] atkbd: cancel delayed work before freeing its structure
Date: Tue, 11 Nov 2008 19:24:21 +0100	[thread overview]
Message-ID: <20081111182421.GA22518@redhat.com> (raw)
In-Reply-To: <20081111112741.ZZRA012@mailhub.coreip.homeip.net>

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.


      reply	other threads:[~2008-11-11 17:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-05 14:31 [PATCH] atkbd: cancel delayed work before freeing its structure Jiri Pirko
2008-11-07 15:43 ` Oleg Nesterov
2008-11-11 14:51   ` Dmitry Torokhov
2008-11-11 17:20     ` Oleg Nesterov
2008-11-11 16:30       ` Dmitry Torokhov
2008-11-11 18:24         ` Oleg Nesterov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081111182421.GA22518@redhat.com \
    --to=oleg@redhat.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jpirko@redhat.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.