From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Hubert Jasudowicz" <hubert.jasudowicz@cert.pl>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Julien Grall" <julien@xen.org>, "Wei Liu" <wl@xen.org>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"George Dunlap" <George.Dunlap@eu.citrix.com>,
"Paul Durrant" <paul@xen.org>,
"Michał Leszczyński" <michal.leszczynski@cert.pl>,
"Ian Jackson" <ian.jackson@citrix.com>,
Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 3/5] xen/memory: Fix compat XENMEM_acquire_resource for size requests
Date: Fri, 31 Jul 2020 09:52:02 +0200 [thread overview]
Message-ID: <dd3a8e3f-fe09-6d71-1ef6-13e6e1a7ea00@suse.com> (raw)
In-Reply-To: <d3c31bea-0c31-5822-15cb-226402c4ae75@citrix.com>
On 30.07.2020 21:12, Andrew Cooper wrote:
> On 29/07/2020 21:09, Jan Beulich wrote:
>> On 28.07.2020 13:37, Andrew Cooper wrote:
>>> Copy the nr_frames from the correct structure, so the caller doesn't
>>> unconditionally receive 0.
>>
>> Well, no - it does get copied from the correct structure. It's just
>> that the field doesn't get set properly up front.
>
> You appear to be objecting to my use of the term "correct".
>
> There are two structures. One contains the correct value, and one
> contains the wrong value, which happens to always be 0.
>
> I stand by sentence as currently written.
At the risk of splitting hair, what you copy from is a field holding
the correct value, but not the correct field. This only works
correctly because of the way __copy_field_{from,to}_guest() happen
to be implemented; there are possible alternative implementations
where this would break, despite ...
>> Otherwise you'll
>> (a) build in an unchecked assumption that the native and compat
>> fields match in type
>
> Did you actually check? Because I did before embarking on this course
> of action.
>
> In file included from /local/xen.git/xen/include/xen/guest_access.h:10:0,
> from compat/memory.c:5:
> /local/xen.git/xen/include/asm/guest_access.h:152:28: error: comparison
> of distinct pointer types lacks a cast [-Werror]
> (void)(&(hnd).p->field == _s); \
> ^
> compat/memory.c:628:22: note: in expansion of macro ‘__copy_field_to_guest’
> if ( __copy_field_to_guest(
> ^~~~~~~~~~~~~~~~~~~~~
>
> This is what the compiler thinks of the code, when nr_frames is changed
> from uint32_t to unsigned long.
... this type safety check (which, I admit, I didn't consider when
writing my reply). I continue to think that handle and struct should
match up not just for {,__}copy_{from,to}_guest() but also for
{,__}copy_field_{from,to}_guest().
>> and (b) set a bad example for people looking
>> here
>
> This entire function is a massive set of bad examples; the worst IMO
> being the fact that there isn't a single useful comment anywhere in it
> concerning how the higher level loop structure works.
>
> I'm constantly annoyed that I need to reverse engineer it from scratch
> every time I look at it, despite having a better-than-most understanding
> of what it is trying to achieve, and how it is supposed to work.
>
> I realise this is noones fault in particular, but it is not
> fair/reasonable to claim that this change is the thing setting a bad
> example in this file.
I'd be happy to see "bad examples" be corrected. As stated at various
occasions, at the time I first implemented the compat layer this seemed
like the most reasonable approach to me. If you see room for
improvement, then I'm all for it.
>> and then cloning this code in perhaps a case where (a) is not
>> even true. If you agree, the alternative change of setting
>> cmp.mar.nr_frames from nat.mar->nr_frames before the call is
>
> Is there more to this sentence?
I guess I can't figure what you mean here.
> While this example could be implemented (at even higher overhead) by
> copying nat back to cmp before passing it back to the guest, the same is
> not true for the changes required to fix batching (which is another
> series the same size as this).
I'll see when you post this, but I think we will want the principle
outlined above to continue to hold.
Jan
next prev parent reply other threads:[~2020-07-31 7:52 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 11:37 [PATCH 0/5] Multiple fixes to XENMEM_acquire_resource Andrew Cooper
2020-07-28 11:37 ` [PATCH 1/5] xen/memory: Introduce CONFIG_ARCH_ACQUIRE_RESOURCE Andrew Cooper
2020-07-29 19:41 ` Jan Beulich
2020-07-30 8:02 ` Paul Durrant
2020-07-30 17:34 ` Andrew Cooper
2020-07-30 18:24 ` Paul Durrant
2020-07-30 9:50 ` Julien Grall
2020-07-30 17:28 ` Andrew Cooper
2020-07-30 18:30 ` Julien Grall
2020-07-28 11:37 ` [PATCH 2/5] xen/gnttab: Rework resource acquisition Andrew Cooper
2020-07-28 14:11 ` Andrew Cooper
2020-07-29 20:02 ` Jan Beulich
2020-09-22 13:10 ` Andrew Cooper
2020-09-22 13:34 ` Jan Beulich
2020-09-22 14:50 ` Andrew Cooper
2020-09-22 16:01 ` Jan Beulich
2020-07-30 8:14 ` Paul Durrant
2020-09-22 13:13 ` Andrew Cooper
2020-07-30 10:56 ` Julien Grall
2020-07-28 11:37 ` [PATCH 3/5] xen/memory: Fix compat XENMEM_acquire_resource for size requests Andrew Cooper
2020-07-29 20:09 ` Jan Beulich
2020-07-30 19:12 ` Andrew Cooper
2020-07-31 7:52 ` Jan Beulich [this message]
2020-07-30 8:19 ` Paul Durrant
2020-07-28 11:37 ` [PATCH 4/5] xen/memory: Fix acquire_resource size semantics Andrew Cooper
2020-07-30 8:31 ` Paul Durrant
2020-07-30 12:54 ` Julien Grall
2020-07-30 19:53 ` Andrew Cooper
2020-07-30 19:46 ` Andrew Cooper
2020-07-30 20:00 ` Julien Grall
2020-07-31 14:31 ` Jan Beulich
2020-07-31 14:44 ` Jan Beulich
2020-07-31 14:53 ` Andrew Cooper
2020-07-28 11:37 ` [PATCH 5/5] tools/foreignmem: Support querying the size of a resource Andrew Cooper
2020-07-28 14:14 ` Andrew Cooper
2020-08-04 14:29 ` Wei Liu
2020-07-30 8:39 ` Paul Durrant
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=dd3a8e3f-fe09-6d71-1ef6-13e6e1a7ea00@suse.com \
--to=jbeulich@suse.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=hubert.jasudowicz@cert.pl \
--cc=ian.jackson@citrix.com \
--cc=julien@xen.org \
--cc=konrad.wilk@oracle.com \
--cc=michal.leszczynski@cert.pl \
--cc=paul@xen.org \
--cc=sstabellini@kernel.org \
--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 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).