All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Mickler <florian@mickler.org>
To: James Bottomley <James.Bottomley@suse.de>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	markgross@thegnar.org, linville@tuxdriver.com,
	linux-kernel@vger.kernel.org,
	pm list <linux-pm@lists.linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v4] pm_qos: make update_request non blocking
Date: Wed, 9 Jun 2010 18:00:33 +0200	[thread overview]
Message-ID: <20100609180033.39d5b499__28304.0639864796$1276099302$gmane$org@schatten.dmk.lab> (raw)
In-Reply-To: <1276097832.4343.223.camel@mulgrave.site>

On Wed, 09 Jun 2010 11:37:12 -0400
James Bottomley <James.Bottomley@suse.de> wrote:


> This still isn't resilient against two successive calls to update.  If
> the second one gets to schedule_work() before the work of the first one
> has finished, you'll corrupt the workqueue.

Sorry, I don't see it. Can you elaborate?

In "run_workqueue(" we do a list_del_init() which resets the
list-pointers of the workitem and only after that reset the
WORK_STRUCT_PENDING member of said structure. 


schedule_work does a queue_work_on which does a test_and_set_bit on
the WORK_STRUCT_PENDING member of the work and only queues the work
via list_add_tail in insert_work afterwards.

Where is my think'o? Or was this fixed while you didn't look?

So what _can_ happen, is that we miss a new notfication while the old
notification is still in the queue. But I don't think this is a problem.

Cheers,
Flo

  reply	other threads:[~2010-06-09 16:00 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-09 15:29 [PATCH v4] pm_qos: make update_request non blocking florian
2010-06-09 15:37 ` James Bottomley
2010-06-09 15:37 ` James Bottomley
2010-06-09 16:00   ` Florian Mickler [this message]
2010-06-09 16:00   ` Florian Mickler
2010-06-09 16:07     ` James Bottomley
2010-06-09 16:07     ` James Bottomley
2010-06-09 16:32       ` Florian Mickler
2010-06-09 17:05         ` James Bottomley
2010-06-09 17:05         ` James Bottomley
2010-06-09 17:31           ` Florian Mickler
2010-06-09 17:31           ` Florian Mickler
2010-06-10  7:45           ` Florian Mickler
2010-06-10 13:39             ` James Bottomley
2010-06-10 13:39             ` [linux-pm] " James Bottomley
2010-06-10 14:41               ` Florian Mickler
2010-06-11 14:25                 ` James Bottomley
2010-06-11 14:25                 ` [linux-pm] " James Bottomley
2010-06-11 15:49                   ` Florian Mickler
2010-06-11 15:49                   ` [linux-pm] " Florian Mickler
2010-06-14 14:33                   ` Florian Mickler
2010-06-14 14:33                   ` [linux-pm] " Florian Mickler
2010-06-14 14:44                     ` James Bottomley
2010-06-14 14:44                     ` [linux-pm] " James Bottomley
2010-06-14 14:49                       ` Florian Mickler
2010-06-14 14:49                       ` [linux-pm] " Florian Mickler
2010-06-14 15:10                         ` James Bottomley
2010-06-14 15:20                           ` Florian Mickler
2010-06-14 15:20                           ` [linux-pm] " Florian Mickler
2010-06-14 15:10                         ` James Bottomley
2010-06-14 14:46                   ` [PATCH 1/3] " florian
2010-06-14 14:46                   ` [PATCH 2/3] pm_qos: add atomic notifier chain florian
2010-06-14 14:46                   ` [PATCH 3/3] pm_qos: only schedule work when in interrupt context florian
2010-06-15 17:23                     ` Florian Mickler
2010-06-15 17:23                     ` Florian Mickler
2010-06-17 23:02                       ` James Bottomley
2010-06-17 23:02                       ` James Bottomley
2010-06-10 14:41               ` [PATCH v4] pm_qos: make update_request non blocking Florian Mickler
2010-06-10  7:45           ` Florian Mickler
2010-06-09 16:32       ` Florian Mickler
2010-06-09 15:29 florian

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='20100609180033.39d5b499__28304.0639864796$1276099302$gmane$org@schatten.dmk.lab' \
    --to=florian@mickler.org \
    --cc=James.Bottomley@suse.de \
    --cc=corbet@lwn.net \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=linville@tuxdriver.com \
    --cc=markgross@thegnar.org \
    --cc=tglx@linutronix.de \
    /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.