Re: [XEN PATCH v3] xen/mm: address violations of MISRA C:2012 Rules 8.2 and 8.3

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 16 Oct 2023, Jan Beulich wrote:
> On 03.10.2023 17:24, Federico Serafini wrote:
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -5901,17 +5901,17 @@ int destroy_xen_mappings(unsigned long s, unsigned 
> > long e)
> >   * a problem.
> >   */
> >  void init_or_livepatch modify_xen_mappings_lite(
> > -    unsigned long s, unsigned long e, unsigned int _nf)
> > +    unsigned long s, unsigned long e, unsigned int nf)
> >  {
> > -    unsigned long v = s, fm, nf;
> > +    unsigned long v = s, fm, flags;
> 
> While it looks correct, I consider this an unacceptably dangerous
> change: What if by the time this is to be committed some new use of
> the local "nf" appears, without resulting in fuzz while applying the
> patch? Imo this needs doing in two steps: First nf -> flags, then
> _nf -> nf.

Wouldn't it be sufficient for the committer to pay special attention
when committing this patch? We are in code freeze anyway, the rate of
changes affecting staging is low.