mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com>
To: Matt Redfearn <matt.redfearn@imgtec.com>,
	Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org,
	Marcin Nowakowski <marcin.nowakowski@imgtec.com>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Paul Burton <paul.burton@imgtec.com>
Subject: Re: [PATCH] MIPS: Revert "MIPS: Fix race on setting and getting cpu_online_mask"
Date: Mon, 28 Aug 2017 12:07:54 +0200	[thread overview]
Message-ID: <71ea8331-78da-c22b-d46d-99ab6c187bbf@nokia.com> (raw)
In-Reply-To: <1503476475-21069-1-git-send-email-matt.redfearn@imgtec.com>

On 08/23/2017 10:21 AM, Matt Redfearn wrote:
> As noted in the commit message, upstream differs in this area. The
> hotplug code now waits on a completion event in bringup_wait_for_ap,
> which is set by the starting CPU in cpuhp_online_idle once it calls
> cpu_startup_entry. Thus there is no possibility of a race in upstream,
> and this commit has only re-introduced the deadlock condition, which can
> be observed on multiple platforms when running a heavy load test at the
> same time as hotplugging CPUs. See commit 8f46cca1e6c06 ("MIPS: SMP: Fix
> possibility of deadlock when bringing CPUs online") for details.

I personally do not like the fact that synchronization is implicitly done by the callers, it is the reason why the patch was proposed. As noted before, it is enough someone checks cpu online mask somewhere in between and there is race again.

How about moving synchronise_count_slave before setting the cpu online? Is there dependency it has to be done after completion?

Regards,

Matija

  reply	other threads:[~2017-08-28 10:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-23  8:21 Matt Redfearn
2017-08-28 10:07 ` Matija Glavinic Pecotic [this message]
2017-08-29  1:43   ` Huacai Chen
2017-08-30 13:24     ` Matt Redfearn
2017-08-31  7:03       ` Huacai Chen

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=71ea8331-78da-c22b-d46d-99ab6c187bbf@nokia.com \
    --to=matija.glavinic-pecotic.ext@nokia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=marcin.nowakowski@imgtec.com \
    --cc=matt.redfearn@imgtec.com \
    --cc=mingo@kernel.org \
    --cc=paul.burton@imgtec.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=ralf@linux-mips.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

all inboxes | Powered by JetHome®