[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH][for-4.19 v4] xen: address violations of Rule 11.9



On Tue, 14 Nov 2023, Nicola Vetrini wrote:
> On 2023-11-14 08:19, Jan Beulich wrote:
> > On 14.11.2023 00:58, Stefano Stabellini wrote:
> > > On Mon, 13 Nov 2023, Jan Beulich wrote:
> > > > On 19.10.2023 09:55, Nicola Vetrini wrote:
> > > > > The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a
> > > > > compile-time check to detect non-scalar types; its usage for this
> > > > > purpose is deviated.
> > > > > 
> > > > > Furthermore, the 'typeof_field' macro is introduced as a general way
> > > > > to access the type of a struct member without declaring a variable
> > > > > of struct type. Both this macro and 'sizeof_field' are moved to
> > > > > 'xen/macros.h'.
> > > > > 
> > > > > No functional change intended.
> > > > > 
> > > > > Signed-off-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
> > > > > Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> > > > > Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> > > > > ---
> > > > > Changes in v2:
> > > > > - added entry in deviations.rst
> > > > > Changes in v3:
> > > > > - dropped access_field
> > > > > - moved macro to macros.h
> > > > > ---
> > > > > Changes in v4:
> > > > > - Amend deviation record.
> > > > > ---
> > > > >  automation/eclair_analysis/ECLAIR/deviations.ecl |  9 +++++++++
> > > > >  docs/misra/deviations.rst                        |  6 ++++++
> > > > >  xen/include/xen/compiler.h                       |  8 --------
> > > > >  xen/include/xen/kernel.h                         |  2 +-
> > > > >  xen/include/xen/macros.h                         | 16
> > > > > ++++++++++++++++
> > > > >  5 files changed, 32 insertions(+), 9 deletions(-)
> > > > 
> > > > I tried to commit this patch, but ...
> > > > 
> > > > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > > > b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > > > index fa56e5c00a27..28d9c37bedb2 100644
> > > > > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > > > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > > > @@ -246,6 +246,15 @@ constant expressions are required.\""
> > > > >    "any()"}
> > > > >  -doc_end
> > > > > 
> > > > > +#
> > > > > +# Series 11
> > > > > +#
> > > > > +
> > > > > +-doc_begin="This construct is used to check if the type is scalar,
> > > > > and for this purpose the use of 0 as a null pointer constant is
> > > > > deliberate."
> > > > > +-config=MC3R1.R11.9,reports+={deliberate,
> > > > > "any_area(any_loc(any_exp(macro(^__ACCESS_ONCE$))))"
> > > > > +}
> > > > > +-doc_end
> > > > > +
> > > > >  #
> > > > >  # Series 13
> > > > >  #
> > > > 
> > > > ... this change doesn't apply, and I also can't see how it would. There
> > > > were
> > > > no dependencies specified, so it's also not clear on top of which other
> > > > (ready to be committed) patch(es) this might have been meant to apply.
> > > > Please
> > > > resubmit in a shape applicable to the staging branch.
> > > 
> > > The order doesn't matter in that file, you can place # Series 11 just
> > > after # Series 10
> > 
> > That would have been one of the possible guesses. Yet then ...
> > 
> > > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > @@ -274,6 +274,15 @@ still non-negative."
> > >  -config=MC3R1.R10.1,etypes+={safe,
> > > "stmt(operator(logical)||node(conditional_operator||binary_conditional_operator))",
> > > "dst_type(ebool||boolean)"}
> > >  -doc_end
> > > 
> > > +#
> > > +# Series 11
> > > +#
> > > +
> > > +-doc_begin="This construct is used to check if the type is scalar, and
> > > for this purpose the use of 0 as a null pointer constant is deliberate."
> > > +-config=MC3R1.R11.9,reports+={deliberate,
> > > "any_area(any_loc(any_exp(macro(^__ACCESS_ONCE$))))"
> > > +}
> > > +-doc_end
> > > +
> > >  ### Set 3 ###
> > 
> > ... there is this grouping by sets as well.
> > 
> 
> +Stefano
> 
> I think the culprit here is that this commit 699899f44d09
> was never merged with 4.19. Is that correct? My own tree is rebased
> against that.

699899f44d09 is "automation/eclair: update deviations and accepted
guidelines" and should go in.

I'll wait until the release which should be imminent and then commit
both commits (if Jan doesn't beat me to it)



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.