All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Bob Liu <lliubbo@gmail.com>,
	ian.campbell@citrix.com, andrew.cooper3@citrix.com,
	dario.faggioli@citrix.com, xen-devel@lists.xen.org
Subject: Re: [RFC PATCH 2/2] xen: tmem: make tmem aware of NUMA affinity
Date: Wed, 19 Mar 2014 13:12:32 -0400	[thread overview]
Message-ID: <20140319171232.GA5247@phenom.dumpdata.com> (raw)
In-Reply-To: <5328665E02000078001252AC@nat28.tlf.novell.com>

On Tue, Mar 18, 2014 at 02:29:34PM +0000, Jan Beulich wrote:
> >>> On 18.03.14 at 13:25, Bob Liu <lliubbo@gmail.com> wrote:
> > Persistant pages in tmem are allocated by alloc_domheap_pages(domain) which
> > is consistent with that domain's node affinity. But that's not true for
> > ephemeral pages, because domain=NULL have to be passed to
> > alloc_domheap_pages(NULL).
> > 
> > This patch makes use of function alloc_domheap_pages_nodemask() introduced 
> > by
> > previous patch, so that we can still only allocate memory from nodes in
> > d->node_affinity even when domain=NULL.
> > 
> > Signed-off-by: Bob Liu <bob.liu@oracle.com>
> 
> While this may be considered reasonable, I don't think we want to
> see feature enhancements to tmem prior to the security audit
> having happened that has been outstanding for about 1.5 years
> (XSA-15).

Hey Jan,

Bob has been going through the code to make it easier to understand
and also easier to analyze. As part of that it has already removed
some of the issues that at least Coverity has identified.

While I concur with your that adding this patch right now
might distract from the security aspects, I hope to have the
Coverity not report any issues for tmem. The posting of cleanup
patches that Bob had done in February addressed a lot of them -
and I finally got through them and are testing them.

Now Coverity is not the end answer to static analysis so we are
looking at using other tools to augment this.

The paper and pen methodology - which is what both me and Bob
had been using has been instrumental in the creation of the
cleanup patches to simplify some of the code paths.

It is not complete, but I hope by Xen 4.5 it will be done.

Would you perhaps reconsider reviewing the code that Bob
posted and ignore the committing part of it until a later time
(when tmem has gotten throught the security audit).

Thanks!
> 
> Jan
> 

  reply	other threads:[~2014-03-19 17:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-18 12:25 [RFC PATCH 1/2] xen: page_alloc: introduce alloc_domheap_pages_nodemask() Bob Liu
2014-03-18 12:25 ` [RFC PATCH 2/2] xen: tmem: make tmem aware of NUMA affinity Bob Liu
2014-03-18 14:29   ` Jan Beulich
2014-03-19 17:12     ` Konrad Rzeszutek Wilk [this message]
2014-03-20  9:26       ` Jan Beulich
2014-03-20 11:59         ` Bob Liu
2014-03-20 12:30           ` Jan Beulich
2014-03-19 18:54 ` [RFC PATCH 1/2] xen: page_alloc: introduce alloc_domheap_pages_nodemask() Dario Faggioli

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=20140319171232.GA5247@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=lliubbo@gmail.com \
    --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 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.