From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>
Subject: Re: [PATCH 1/4] x86: move syscall trampolines off the stack
Date: Wed, 20 May 2015 14:58:28 +0100 [thread overview]
Message-ID: <555C9304.2080702@citrix.com> (raw)
In-Reply-To: <555CAA3F020000780007C38E@mail.emea.novell.com>
On 20/05/15 14:37, Jan Beulich wrote:
>>>> On 19.05.15 at 18:59, <andrew.cooper3@citrix.com> wrote:
>> On 18/05/15 13:46, Jan Beulich wrote:
>>> @@ -616,6 +653,24 @@ static void cpu_smpboot_free(unsigned in
>>> free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
>>> free_cpumask_var(per_cpu(cpu_core_mask, cpu));
>>>
>>> + if ( per_cpu(stubs.addr, cpu) )
>>> + {
>>> + unsigned long mfn = per_cpu(stubs.mfn, cpu);
>>> + unsigned char *stub_page = map_domain_page(mfn);
>>> + unsigned int i;
>>> +
>>> + memset(stub_page + (cpu & (STUBS_PER_PAGE - 1)) * STUB_BUF_SIZE,
>>> + 0xcc, STUB_BUF_SIZE);
>>> + for ( i = 0; i < STUBS_PER_PAGE; ++i )
>>> + if ( stub_page[i * STUB_BUF_SIZE] != 0xcc)
>>> + break;
>> There is a race condition between allocate and free, as
>> write_stub_trampoline() is written by the cpu itself. Just finding 0xcc
>> here doesn't mean there isn't a different cpu in the process of coming
>> up and intending to use the stub page.
> No, there is no race afaict: percpu_traps_init() gets called before
> a CPU is marked online and hence before __cpu_up() returns, and
> thus before the CPU hotplug lock gets dropped, so there can't be
> any CPUs going down concurrently.
Thinking out loud...
cpu_up/down have excusion due to the recursive spinlock used by
cpu_hotplug_begin/end.
The allocate is done by the CPU_UP_PREPARE notifier chain, and
__cpu_up() does wait until the AP has marked itself as online.
Therefore, so long as no CPU_UP_PREPARE action triggers a
CPU_UP_CANCELED or CPU_DEAD chain against the same cpu, we are safe.
~Andrew
next prev parent reply other threads:[~2015-05-20 13:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-18 10:28 [PATCH 0/4] x86: don't default to executable mappings Jan Beulich
2015-05-18 12:46 ` [PATCH 1/4] x86: move syscall trampolines off the stack Jan Beulich
2015-05-18 18:39 ` Andrew Cooper
2015-05-19 6:41 ` Jan Beulich
2015-05-19 9:24 ` Andrew Cooper
2015-05-19 16:59 ` Andrew Cooper
2015-05-20 9:16 ` Jan Beulich
2015-05-20 13:37 ` Jan Beulich
2015-05-20 13:58 ` Andrew Cooper [this message]
2015-05-20 15:54 ` Jan Beulich
2015-05-18 12:46 ` [PATCH 2/4] x86emul: move stubs " Jan Beulich
2015-05-19 17:33 ` Andrew Cooper
2015-05-20 9:25 ` Jan Beulich
2015-05-18 12:47 ` [PATCH 3/4] x86: move I/O emulation " Jan Beulich
2015-05-19 17:48 ` Andrew Cooper
2015-05-20 13:57 ` Jan Beulich
2015-05-18 12:47 ` [PATCH 4/4] x86: switch default mapping attributes to non-executable Jan Beulich
2015-05-19 18:53 ` Andrew Cooper
2015-05-20 9:32 ` Jan Beulich
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=555C9304.2080702@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xenproject.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).