All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 1/6] x86/p2m: tidy p2m_add_foreign() a little
Date: Fri, 18 Dec 2020 09:39:28 +0100	[thread overview]
Message-ID: <54d8249e-9c47-3967-f069-2dd38a9e138d@suse.com> (raw)
In-Reply-To: <55de56b3-0e83-c558-6432-9853db82f57a@citrix.com>

On 17.12.2020 20:03, Andrew Cooper wrote:
> On 15/12/2020 16:25, Jan Beulich wrote:
>> Drop a bogus ASSERT() - we don't typically assert incoming domain
>> pointers to be non-NULL, and there's no particular reason to do so here.
>>
>> Replace the open-coded DOMID_SELF check by use of
>> rcu_lock_remote_domain_by_id(), at the same time covering the request
>> being made with the current domain's actual ID.
>>
>> Move the "both domains same" check into just the path where it really
>> is meaningful.
>>
>> Swap the order of the two puts, such that
>> - the p2m lock isn't needlessly held across put_page(),
>> - a separate put_page() on an error path can be avoided,
>> - they're inverse to the order of the respective gets.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks.

>> ---
>> The DOMID_SELF check being converted also suggests to me that there's an
>> implication of tdom == current->domain, which would in turn appear to
>> mean the "both domains same" check could as well be dropped altogether.
> 
> I don't see anything conceptually wrong with the toolstack creating a
> foreign mapping on behalf of a guest at construction time.  I'd go as
> far as to argue that it is an interface shortcoming if this didn't
> function correctly.

Right, I actually didn't get the remark right. It's the DOMID_SELF
check that's suspicious especially when tdom != current->domain,
not the tdom != fdom one.

Jan


  reply	other threads:[~2020-12-18  8:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-15 16:24 [PATCH 0/6] x86/p2m: restrict more code to build just for HVM Jan Beulich
2020-12-15 16:25 ` [PATCH 1/6] x86/p2m: tidy p2m_add_foreign() a little Jan Beulich
2020-12-17 19:03   ` Andrew Cooper
2020-12-18  8:39     ` Jan Beulich [this message]
2020-12-15 16:26 ` [PATCH 2/6] x86/mm: p2m_add_foreign() is HVM-only Jan Beulich
2020-12-17 19:18   ` Andrew Cooper
2020-12-18  8:48     ` Jan Beulich
2020-12-21  8:10     ` Jan Beulich
2020-12-22 10:40       ` Andrew Cooper
2021-01-04 16:57         ` Oleksandr Tyshchenko
2021-01-05  8:48           ` Jan Beulich
2021-01-08 16:38             ` Oleksandr
2021-01-08 17:01               ` Jan Beulich
2021-01-08 17:37                 ` Oleksandr
2021-01-11  7:41                   ` Jan Beulich
2021-01-11  8:23                     ` Oleksandr
2021-01-12 11:58                       ` Jan Beulich
2021-01-13 15:06                         ` Oleksandr
2021-01-23 13:22                           ` Julien Grall
2021-01-25  9:10                             ` Jan Beulich
2021-01-25 10:33                             ` Jan Beulich
2020-12-15 16:26 ` [PATCH 3/6] x86/p2m: set_{foreign,mmio}_p2m_entry() are HVM-only Jan Beulich
2020-12-17 19:54   ` Andrew Cooper
2020-12-18  8:58     ` Jan Beulich
2020-12-15 16:26 ` [PATCH 4/6] x86/p2m: {,un}map_mmio_regions() " Jan Beulich
2020-12-15 16:27 ` [PATCH 5/6] x86/mm: the gva_to_gfn() hook is HVM-only Jan Beulich
2020-12-22 17:02   ` Jan Beulich
2020-12-15 16:28 ` [PATCH 6/6] x86/p2m: set_shared_p2m_entry() is MEM_SHARING-only Jan Beulich
2020-12-15 17:05   ` Tamas K Lengyel

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=54d8249e-9c47-3967-f069-2dd38a9e138d@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@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 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.