Re: [Xen-devel] [PATCH v4 6/9] x86/mm: add an end_of_loop label in map_pages_to_xen

["Durrant, Paul" <pdurrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Jan
> Beulich
> Sent: 05 December 2019 10:26
> To: Xia, Hongyan <hongyxia@xxxxxxxxxx>
> Cc: andrew.cooper3@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx; wl@xxxxxxx;
> roger.pau@xxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH v4 6/9] x86/mm: add an end_of_loop label
> in map_pages_to_xen
> 
> 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).

And what is wrong with using goto-s? It is a *very* common style of error 
handling use widely in e.g. the linux kernel. IMO it often makes error paths 
much more obvious and easier to reason about. In fact I very much dislike 
returns from the middle of functions as they can easily lead to avoidance of 
necessary error cleanup.

  Paul

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