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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.12.2019 12:02, Durrant, Paul wrote:
>> -----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.

Whereas I personally dislike goto-s (and I've been taught so when
first learning programming languages). In private code I avoid them
by all means. In projects I'm the maintainer for I accept them when
the alternative is noticeably more ugly.

Jan

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