All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Anish Kumar <anish198519851985@gmail.com>
Subject: [PATCH 1/9] irq_work: Fix racy IRQ_WORK_BUSY flag setting
Date: Sun, 18 Nov 2012 02:04:44 +0100	[thread overview]
Message-ID: <1353200692-6039-2-git-send-email-fweisbec@gmail.com> (raw)
In-Reply-To: <1353200692-6039-1-git-send-email-fweisbec@gmail.com>

The IRQ_WORK_BUSY flag is set right before we execute the
work. Once this flag value is set, the work enters a
claimable state again.

So if we have specific data to compute in our work, we ensure it's
either handled by another CPU or locally by enqueuing the work again.
This state machine is guanranteed by atomic operations on the flags.

So when we set IRQ_WORK_BUSY without using an xchg-like operation,
we break this guarantee as in the following summarized scenario:

        CPU 1                                   CPU 2
        -----                                   -----
                                                (flags = 0)
                                                old_flags = flags;
        (flags = 0)
        cmpxchg(flags, old_flags,
                old_flags | IRQ_WORK_FLAGS)
        (flags = 3)
        [...]
        flags = IRQ_WORK_BUSY
        (flags = 2)
        func()
                                                (sees flags = 3)
                                                cmpxchg(flags, old_flags,
                                                        old_flags | IRQ_WORK_FLAGS)
                                                (give up)

        cmpxchg(flags, 2, 0);
        (flags = 0)

CPU 1 claims a work and executes it, so it sets IRQ_WORK_BUSY and
the work is again in a claimable state. Now CPU 2 has new data to process
and try to claim that work but it may see a stale value of the flags
and think the work is still pending somewhere that will handle our data.
This is because CPU 1 doesn't set IRQ_WORK_BUSY atomically.

As a result, the data expected to be handle by CPU 2 won't get handled.

To fix this, use xchg() to set IRQ_WORK_BUSY, this way we ensure the CPU 2
will see the correct value with cmpxchg() using the expected ordering.

Changelog-heavily-inspired-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Anish Kumar <anish198519851985@gmail.com>
---
 kernel/irq_work.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/kernel/irq_work.c b/kernel/irq_work.c
index 1588e3b..57be1a6 100644
--- a/kernel/irq_work.c
+++ b/kernel/irq_work.c
@@ -119,8 +119,11 @@ void irq_work_run(void)
 		/*
 		 * Clear the PENDING bit, after this point the @work
 		 * can be re-used.
+		 * Make it immediately visible so that other CPUs trying
+		 * to claim that work don't rely on us to handle their data
+		 * while we are in the middle of the func.
 		 */
-		work->flags = IRQ_WORK_BUSY;
+		xchg(&work->flags, IRQ_WORK_BUSY);
 		work->func(work);
 		/*
 		 * Clear the BUSY bit and return to the free state if
-- 
1.7.5.4


  reply	other threads:[~2012-11-18  1:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-18  1:04 [GIT PULL v2] printk: Make it usable on nohz cpus Frederic Weisbecker
2012-11-18  1:04 ` Frederic Weisbecker [this message]
2012-11-18  1:04 ` [PATCH 2/9] irq_work: Fix racy check on work pending flag Frederic Weisbecker
2012-11-18  1:04 ` [PATCH 3/9] irq_work: Remove CONFIG_HAVE_IRQ_WORK Frederic Weisbecker
2012-11-18  1:04 ` [PATCH 4/9] nohz: Add API to check tick state Frederic Weisbecker
2012-11-18  1:04 ` [PATCH 5/9] irq_work: Don't stop the tick with pending works Frederic Weisbecker
2012-11-18  1:04 ` [PATCH 6/9] irq_work: Flush work on CPU_DYING Frederic Weisbecker
2012-11-18  1:04 ` [PATCH 7/9] irq_work: Warn if there's still work on cpu_down Frederic Weisbecker
2012-11-18  1:04 ` [PATCH 8/9] irq_work: Make self-IPIs optable Frederic Weisbecker
2012-11-18  1:04 ` [PATCH 9/9] printk: Wake up klogd using irq_work Frederic Weisbecker
2012-12-08 15:02 ` [GIT PULL v2] printk: Make it usable on nohz cpus Ingo Molnar
2012-12-08 22:50   ` Frederic Weisbecker
  -- strict thread matches above, loose matches on Subject: below --
2012-11-16  2:21 [PATCH 0/9] printk: Make it usable on nohz cpus v6 Frederic Weisbecker
2012-11-16  2:21 ` [PATCH 1/9] irq_work: Fix racy IRQ_WORK_BUSY flag setting Frederic Weisbecker

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=1353200692-6039-2-git-send-email-fweisbec@gmail.com \
    --to=fweisbec@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=anish198519851985@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.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.