xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Xia, Hongyan" <hongyxia@amazon.com>
Cc: "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"wl@xen.org" <wl@xen.org>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 6/9] x86/mm: add an end_of_loop label in map_pages_to_xen
Date: Thu, 5 Dec 2019 11:25:53 +0100	[thread overview]
Message-ID: <cb2c4422-f425-721b-2b66-48fe7ba300ce@suse.com> (raw)
In-Reply-To: <f13c0e4808e320a0233f82b9be005fe5b2679469.camel@amazon.com>

On 05.12.2019 11:21, Xia, Hongyan wrote:
>> On 02.10.2019 19:16, Hongyan Xia wrote:
>>> We will soon need to clean up mappings whenever the out most loop is
>>> ended. Add a new label and turn relevant continue's into goto's.
>>
>> I think already when this still was RFC I did indicate that I'm not
>> happy about the introduction of these labels (including also patch 8).
>> I realize it's quite a lot to ask, but both functions would benefit
>>from splitting up into per-level helper functions, which - afaict -
>> would avoid the need for such labels, and which would at the same
>> time likely make it quite a bit easier to extend these to the
>> 5-level page tables case down the road.
> 
> A common pattern I have found when mapping PTE pages on-demand (and I
> think is the exact intention of these labels from Wei, also described
> in the commit message) is that we often need to do:
> 
> map some pages - process those pages - error occurs or this iteration
> of loop can be skipped - _clean up the mappings_ - continue or return
> 
> As long as cleaning up is required, these labels will likely be needed
> as the clean-up path before skipping or returning, so I would say we
> will see such labels even if we split it into helper functions
> (virt_to_xen_l[123]e() later in the patch series is an example). I see
> the labels more or less as orthogonal to modularising into helper
> functions.

I think differently: The fact that labels are needed is because of
the complexity of the functions. Simpler functions would allow
goto-free handling of such error conditions (by instead being able
to use continue, break, or return without making the code less
readable, often even improving readability).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-12-05 10:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04 17:10 [Xen-devel] [PATCH v4 0/9] Add alternative API for Xen PTEs Hongyan Xia
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 1/9] x86: move some xen mm function declarations Hongyan Xia
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 2/9] x86: introduce a new set of APIs to manage Xen page tables Hongyan Xia
2019-12-04 17:54   ` Xia, Hongyan
2019-12-05  7:20     ` Jan Beulich
2019-12-11 16:33   ` Julien Grall
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 3/9] x86/mm: introduce l{1, 2}t local variables to map_pages_to_xen Hongyan Xia
2019-12-04 18:01   ` Xia, Hongyan
2019-12-05  8:38     ` Jan Beulich
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 4/9] x86/mm: introduce l{1, 2}t local variables to modify_xen_mappings Hongyan Xia
2019-12-12 14:34   ` Julien Grall
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 5/9] x86/mm: map_pages_to_xen would better have one exit path Hongyan Xia
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 6/9] x86/mm: add an end_of_loop label in map_pages_to_xen Hongyan Xia
2019-12-05 10:21   ` Xia, Hongyan
2019-12-05 10:25     ` Jan Beulich [this message]
2019-12-05 11:02       ` Durrant, Paul
2019-12-05 11:12         ` Jan Beulich
2019-12-05 13:22           ` Xia, Hongyan
2019-12-06 15:58           ` Xia, Hongyan
2019-12-04 17:10 ` [Xen-devel] [PATCH v4 7/9] x86/mm: make sure there is one exit path for modify_xen_mappings Hongyan Xia
2019-12-04 17:11 ` [Xen-devel] [PATCH v4 8/9] x86/mm: add an end_of_loop label in modify_xen_mappings Hongyan Xia
2019-12-04 17:11 ` [Xen-devel] [PATCH v4 9/9] x86/mm: change pl*e to l*t in virt_to_xen_l*e Hongyan Xia
2019-12-05  9:14 ` [Xen-devel] [PATCH v4 0/9] Add alternative API for Xen PTEs Jan Beulich
2019-12-05  9:41   ` Xia, Hongyan
2019-12-05  9:51     ` Jan Beulich
2019-12-05 10:45       ` Xia, Hongyan

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=cb2c4422-f425-721b-2b66-48fe7ba300ce@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=hongyxia@amazon.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 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).