From: Nicholas Mc Guire <der.herr@hofr.at>
To: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: pavel@pavlinux.ru, RT <linux-rt-users@vger.kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [patch 0/6] 3.14-rt1 fixes
Date: Sat, 3 May 2014 10:32:57 +0200 [thread overview]
Message-ID: <20140503083257.GA16242@opentech.at> (raw)
In-Reply-To: <1399031023.5233.145.camel@marge.simpson.net>
On Fri, 02 May 2014, Mike Galbraith wrote:
> On Fri, 2014-05-02 at 15:39 +0400, Pavel Vasilyev wrote:
> > 02.05.2014 15:12, Mike Galbraith ??????????:
> > > The following patches are fixes that fell out of testing rt1. Patches
> > > 1-4 are intended to be folded into existing patches, 5-6 are
> > > replacements.
> > >
> > > fold:
> > > 1/6 - preempt-lazy-support.patch
> > > 2/6 - x86-preempt-lazy.patch
> > > 3/6 - hotplug-light-get-online-cpus.patch
> > > 4/6 - stomp-machine-raw-lock.patch
> > >
> > > replace:
> > > 5/6 - (prep)
> > > 6/6 - stomp-machine-deal-clever-with-stopper-lock.patch
> > >
> > > drop: (buggy - calls migrate_disable() _after_ maybe blocking)
> > > migrate_disable-pushd-down-in-atomic_dec_and_spin_lo.patch
> >
> >
Why would calling migrate_disable be buggy after blocking ?
at that point any per cpu data is not yet being accessed so its perfectly fine
to
lock->block
-> migrate
-> unblock->lock
-> migrate_disable on a new CPU
-> access per_cpu object
-> migrate_enable
-> unlock
what problems would there be ?
thx!
hofrat
next prev parent reply other threads:[~2014-05-03 8:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 11:12 [patch 0/6] 3.14-rt1 fixes Mike Galbraith
2014-05-02 11:39 ` Pavel Vasilyev
2014-05-02 11:43 ` Mike Galbraith
2014-05-03 8:32 ` Nicholas Mc Guire [this message]
2014-05-03 10:40 ` Mike Galbraith
2014-05-03 12:31 ` Nicholas Mc Guire
2014-05-03 14:03 ` Mike Galbraith
2014-05-03 14:19 ` Nicholas Mc Guire
2014-05-03 15:24 ` Mike Galbraith
2014-05-02 13:44 ` Sebastian Andrzej Siewior
2014-05-02 13:45 ` Mike Galbraith
2014-05-02 13:49 ` Sebastian Andrzej Siewior
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=20140503083257.GA16242@opentech.at \
--to=der.herr@hofr.at \
--cc=bigeasy@linutronix.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=pavel@pavlinux.ru \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=umgwanakikbuti@gmail.com \
/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.