linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dirk.behme@googlemail.com (Dirk Behme)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Fix a race in the vfp_notifier() function on	SMPsystems
Date: Sat, 19 Dec 2009 09:20:44 +0100	[thread overview]
Message-ID: <4B2C8CDC.3070507@googlemail.com> (raw)
In-Reply-To: <20091218145345.GD32481@n2100.arm.linux.org.uk>

On 18.12.2009 15:53, Russell King - ARM Linux wrote:
> On Fri, Dec 18, 2009 at 02:51:41PM +0000, Catalin Marinas wrote:
>> On Fri, 2009-12-18 at 14:47 +0000, Russell King - ARM Linux wrote:
>>> Actually, I think we should go further and kill off THREAD_NOTIFY_RELEASE
>>> completely.  Added a few more people because EP93xx and PXA (well,
>>> Xscale) is now impacted by this change.
>>>
>>> [PATCH] ARM: Convert VFP/Crunch/XscaleCP thread_release() to exit_thread()
>>>
>>> This avoids races in the VFP code where the dead thread may have
>>> state on another CPU.  By moving this code to exit_thread(), we
>>> will be running as the thread, and therefore be running on the
>>> current CPU.
>>>
>>> This means that we can ensure that the only local state is accessed
>>> in the thread notifiers.
>>>
>>> Signed-off-by: Russell King<rmk+kernel@arm.linux.org.uk>
>> [...]
>>>   static int vfp_notifier(struct notifier_block *self, unsigned long cmd, void *v)
>>>   {
>>> @@ -132,8 +135,8 @@ static int vfp_notifier(struct notifier_block *self, unsigned long cmd, void *v)
>>>
>>>          if (cmd == THREAD_NOTIFY_FLUSH)
>>>                  vfp_thread_flush(thread);
>>> -       else
>>> -               vfp_thread_release(thread);
>>> +       else if (cmd == THREAD_NOTIFY_EXIT)
>>> +               vfp_thread_exit(thread);
>>
>> Do we still need the second "if" or "else" will do (though it's safer if
>> anyone adds some extra THREAD_NOTIFY_* in the future.
>
> The previous patch iteration did need it, but this done doesn't.  Killed.

Sorry if I missed something, but any hint where to find the latest 
version of the patch for testing?

Many thanks and best regards

Dirk

  reply	other threads:[~2009-12-19  8:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18 13:45 [PATCH] ARM: Fix a race in the vfp_notifier() function on SMP systems Catalin Marinas
2009-12-18 14:11 ` Russell King - ARM Linux
2009-12-18 14:22   ` [PATCH] ARM: Fix a race in the vfp_notifier() function on SMPsystems Catalin Marinas
2009-12-18 14:25   ` [PATCH] ARM: Fix a race in the vfp_notifier() function on SMP systems Russell King - ARM Linux
2009-12-18 14:47     ` Russell King - ARM Linux
2009-12-18 14:51       ` [PATCH] ARM: Fix a race in the vfp_notifier() function on SMPsystems Catalin Marinas
2009-12-18 14:53         ` Russell King - ARM Linux
2009-12-19  8:20           ` Dirk Behme [this message]
2009-12-22 15:36             ` Russell King - ARM Linux
2009-12-18 22:17       ` [PATCH] ARM: Fix a race in the vfp_notifier() function on SMP systems Ryan Mallon

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=4B2C8CDC.3070507@googlemail.com \
    --to=dirk.behme@googlemail.com \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).