public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: Ben Hutchings <ben@decadent.org.uk>, Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	Stefan Richter <stefanr@s5r6.in-berlin.de>,
	stable@vger.kernel.org
Subject: Re: [PATCH] workqueue: Document exceptions to work item non-reentrancy guarantee
Date: Mon, 17 Feb 2014 21:29:34 -0500	[thread overview]
Message-ID: <5302C58E.1070903@hurleysoftware.com> (raw)
In-Reply-To: <1392687834.10088.17.camel@deadeye.wl.decadent.org.uk>

On 02/17/2014 08:43 PM, Ben Hutchings wrote:
> On Sat, 2014-02-15 at 14:38 -0500, Peter Hurley wrote:
>> Since commit a2c1c57be8d9fd5b716113c8991d3d702eeacf77,
>>    workqueue: consider work function when searching for busy work items
>> work items whose work functions are re-assigned are no longer guaranteed
>> non-reentrancy with the previously assigned work function. For example,
>>
>>          PREPARE_WORK(&work, funcA)
>>          schedule_work(&work)
>>            .
>>          < funcA starts >
>>            .
>>          PREPARE_WORK(&work, funcB)
>>          schedule_work(&work)
>>
>> funcA() may run concurrently with funcB().
>>
>> The work item non-reentrancy guarantee is a crucial design guarantee
>> which, if violated, may not have obvious consequences. For example,
>> the entire firewire subsystem expects the as-documented per-work item
>> non-reentrancy guarantee, which was the behavior prior to the above
>> commit, not the per-work function + per-work item behavior since.
>>
>> Document the known exceptions to this guarantee.
> [...]
>
> It never would have occurred to me that you could safely change the
> function for a work item that is already scheduled or running.
> Especially given that PREPARE_WORK() is just a simple assignment (i.e.
> no serialisation).

process_one_work() has an established order that safely allows for
resetting the work function and scheduling the work, and further
guaranteeing that the new work function will run.

Further, existing memory barriers ensure that
1. The new work function is visible on all cpus before testing if
    the work is already pending.
2. The new work function is stored as the worker's current function
    before the work is marked as not pending.

If this wasn't possible, then single-threaded workqueues could
not be used for multiple functions without flushing work.

I wonder if the floppy driver is broken too.

Regards,
Peter Hurley



  reply	other threads:[~2014-02-18  2:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-15 19:38 [PATCH] workqueue: Document exceptions to work item non-reentrancy guarantee Peter Hurley
2014-02-18  1:43 ` Ben Hutchings
2014-02-18  2:29   ` Peter Hurley [this message]
2014-02-18 15:30     ` Tejun Heo
2014-02-18 16:31       ` Peter Hurley
2014-02-18 16:37         ` Tejun Heo

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=5302C58E.1070903@hurleysoftware.com \
    --to=peter@hurleysoftware.com \
    --cc=ben@decadent.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=tj@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox