From: Chao Peng <chao.p.peng@linux.intel.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: andrew.cooper3@citrix.com, dario.faggioli@citrix.com,
keir@xen.org, boris.ostrovsky@oracle.com,
xen-devel@lists.xen.org
Subject: Re: [PATCH v2] x86: correct socket_cpumask allocation
Date: Thu, 9 Jul 2015 22:36:14 +0800 [thread overview]
Message-ID: <20150709143614.GI3333@pengc-linux.bj.intel.com> (raw)
In-Reply-To: <559E5E03020000780008EA88@mail.emea.novell.com>
On Thu, Jul 09, 2015 at 10:41:55AM +0100, Jan Beulich wrote:
> >>> On 09.07.15 at 10:26, <chao.p.peng@linux.intel.com> wrote:
> > @@ -748,8 +758,9 @@ static int cpu_smpboot_alloc(unsigned int cpu)
> > goto oom;
> > per_cpu(stubs.addr, cpu) = stub_page + STUB_BUF_CPU_OFFS(cpu);
> >
> > - if ( !socket_cpumask[socket] &&
> > - !zalloc_cpumask_var(socket_cpumask + socket) )
> > + if ( secondary_socket_cpumask == NULL &&
> > + (secondary_socket_cpumask = _xzalloc(nr_cpumask_bits / 8,
> > + sizeof(long))) == NULL )
>
> This is horrible since completely type-unsafe, and correct only
> because _xmalloc() happens to allocate more space than requested
> if the size isn't a multiple of MEM_ALIGN. And it makes me realize why
> on IRC I first suggested xzalloc_array(): That would at least have
> taken care of that latent bug. And remember that I did _not_
> suggest _xzalloc(), but xzalloc().
>
> Taken together I think we should stay with using zalloc_cpumask_var(),
> and introduce zap_cpumask_var() (storing NULL in the big NR_CPUS
> case and doing nothing in the small one).
Apart from zap_cpumask_var() there is need to check if cpumask_vat_t is
NULL as well. While that is weird to satisfy compiler for small NR_CPUS case.
> Should I be overlooking
> something that still prevents this from building in both cases, the
> above allocation should be changed to at least be type safe (and I
> guess I'd rather waste a few bytes here than see you add fragile
> casts or some such).
So this solution is finally adopted. The new version is already sent out.
Chao
prev parent reply other threads:[~2015-07-09 14:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-09 8:26 [PATCH v2] x86: correct socket_cpumask allocation Chao Peng
2015-07-09 9:11 ` Dario Faggioli
2015-07-09 9:35 ` Andrew Cooper
2015-07-09 9:41 ` Jan Beulich
2015-07-09 14:36 ` Chao Peng [this message]
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=20150709143614.GI3333@pengc-linux.bj.intel.com \
--to=chao.p.peng@linux.intel.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=dario.faggioli@citrix.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.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).