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 18:20:50 +0100 [thread overview]
Message-ID: <20081111172050.GC18214@redhat.com> (raw)
In-Reply-To: <20081111145155.GA24881@anvil.corenet.prv>
On 11/11, Dmitry Torokhov wrote:
>
> On Fri, Nov 07, 2008 at 04:43:25PM +0100, Oleg Nesterov wrote:
> >
> > While we are here, what is the reason for atkbd_schedule_event_work()->wmb() ?
> > It looks absolutely bogus. Is it for atkbd_event_work() ? In that case it
> > is not needed, it must see all previous STOREs because both queue_work() and
> > run_workqueue() take cwq->lock. And in any case,
> > test_and_set_bit(WORK_STRUCT_PENDING) implies mb().
>
> I wanted to be sure that event_mask is set before we schedule event_work
> and I don't want to rely on details of queue_delayed_work
> implementation. If the fact that queue_delayed_work acts as a barrier
> would be listed part of its published spec I would gladly remove wmb()
> from atkbd.
Yes, queue_delayed_work() acts as a barrier for the work->func(), otherwise
almost any code which uses wqs is broken.
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. And unneeded because queue_work() implies mb(),
but this is not really documented.
Oleg.
next prev parent reply other threads:[~2008-11-11 17:20 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 [this message]
2008-11-11 16:30 ` Dmitry Torokhov
2008-11-11 18:24 ` Oleg Nesterov
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=20081111172050.GC18214@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.