Re: Xen 4.20 release schedule

[Jan Beulich <jbeulich@xxxxxxxx>]

On 30.10.2024 14:25, Andrew Cooper wrote:
> On 21/10/2024 1:02 pm, oleksii.kurochko@xxxxxxxxx wrote:
>> Hello everyone,
>>
>> As there were no objections to the proposed release schedule
>> (https://lore.kernel.org/xen-devel/CAMacjJxEi6PThwH2=NwG3He8eQn39aiaxZCw3bQF7i4YcmjuNw@xxxxxxxxxxxxxx/
>> ), I've updated the wiki with the schedule for Xen 4.20 release
>> (https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes), and
>> it is now accessible from
>> https://xenbits.xen.org/docs/unstable-staging/support-matrix.html.
> 
> I have a blocker to raise (against myself...) and no good idea of how to
> proceed.
> 
> The for_each_bit work has a unexpected bug.
> 
>     for_each_bit ( ... )
>     {
>         if ( ... )
>             break;
>     }
> 
> will fall into an infinite loop.  This is caused by for_each_bit()
> hiding a double for() loop, in order to declare two scope-local
> variables of different types.
> 
> The two variables are one copy of the source expression (really quite
> important to keep), and one unsigned int iterator (improved optimisation
> capability by not using a wider-scope variable).
> 
> Options are (off the top of my head)
> 
> 1) Always take the iterator from outer scope
> 2) Iterator always the same type as the source expression
> 3) Figure out some way of expressing "once" in the outer loop
> 
> Or anything else that I've missed.

How about requiring the use of another auxiliary construct in place of "break"
inside such loop bodies:

#define for_each_bit_break ({ __v = 0; break; })

? Of course the risk remains that people might forget that plain break can't
be used there.

If we expected such may want/need using elsewhere as well, introduce

#define BREAK(stmt...) ({ stmt; break; })

and then use that for for_each_bit_break. Albeit the latter may face your
opposition as to using a statement as macro argument; you didn't like such
in my ASSERT_UNREACHABLE() extension proposal.

Another option, requiring such conditions to come ahead of anything changing
state, would be to require use of "continue" in place of "break". That would
result in a number of useless loop iterations, though. Plus it would require
the exit condition to hold for all subsequent values of "iter", too. IOW not
something I'd seriously consider ...

Jan