All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Stabellini <sstabellini@kernel.org>
To: Julien Grall <julien@xen.org>
Cc: Simone Ballarin <simone.ballarin@bugseng.com>,
	 xen-devel@lists.xenproject.org, consulting@bugseng.com,
	 sstabellini@kernel.org,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [XEN PATCH 1/4] xen/arm: address violations of MISRA C:2012 Rule 13.1
Date: Wed, 18 Oct 2023 18:01:26 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2310181759310.965337@ubuntu-linux-20-04-desktop> (raw)
In-Reply-To: <41d82896-5471-4eaa-8bdd-a192e28d5546@xen.org>

On Wed, 18 Oct 2023, Julien Grall wrote:
> Hi,
> 
> On 18/10/2023 15:18, Simone Ballarin wrote:
> > Rule 13.1: Initializer lists shall not contain persistent side effects
> > 
> > This patch moves expressions with side-effects into new variables before
> > the initializer lists.
> 
> Looking at the code, I feel the commit message should be a bit more verbose
> because they are no apparent side-effects.
> 
> > 
> > Function calls do not necessarily have side-effects, in these cases the
> > GCC pure or const attributes are added when possible.
> 
> You are only adding pure in this patch.
> 
> > 
> > No functional changes.
> > 
> > Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
> > 
> > ---
> > Function attributes pure and const do not need to be added as GCC
> > attributes, they can be added using ECLAIR configurations.
> > ---
> >   xen/arch/arm/device.c              |  6 +++---
> >   xen/arch/arm/guestcopy.c           | 12 ++++++++----
> >   xen/arch/arm/include/asm/current.h |  2 +-
> >   3 files changed, 12 insertions(+), 8 deletions(-)
> > 
> > diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
> > index 1f631d3274..e9be078415 100644
> > --- a/xen/arch/arm/device.c
> > +++ b/xen/arch/arm/device.c
> > @@ -319,6 +319,8 @@ int handle_device(struct domain *d, struct
> > dt_device_node *dev, p2m_type_t p2mt,
> >       int res;
> >       paddr_t addr, size;
> >       bool own_device = !dt_device_for_passthrough(dev);
> > +    bool dev_is_hostbridge = is_pci_passthrough_enabled() &&
> > +                             device_get_class(dev) ==
> > DEVICE_PCI_HOSTBRIDGE;
> 
> The commit message suggests that the code is moved because there are
> side-effects. But none of them should have any side-effects.
> 
> In fact, if I am not mistaken, both is_pci_passthrough_enabled() and
> device_get_class() could be marked as pure.
> 
> >       /*
> >        * We want to avoid mapping the MMIO in dom0 for the following cases:
> >        *   - The device is owned by dom0 (i.e. it has been flagged for
> > @@ -329,9 +331,7 @@ int handle_device(struct domain *d, struct
> > dt_device_node *dev, p2m_type_t p2mt,
> >       struct map_range_data mr_data = {
> >           .d = d,
> >           .p2mt = p2mt,
> > -        .skip_mapping = !own_device ||
> > -                        (is_pci_passthrough_enabled() &&
> > -                        (device_get_class(dev) == DEVICE_PCI_HOSTBRIDGE)),
> > +        .skip_mapping = !own_device || dev_is_hostbridge,
> >           .iomem_ranges = iomem_ranges,
> >           .irq_ranges = irq_ranges
> >       };
> > diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
> > index 6716b03561..3ec6743bf6 100644
> > --- a/xen/arch/arm/guestcopy.c
> > +++ b/xen/arch/arm/guestcopy.c
> > @@ -109,27 +109,31 @@ static unsigned long copy_guest(void *buf, uint64_t
> > addr, unsigned int len,
> >     unsigned long raw_copy_to_guest(void *to, const void *from, unsigned int
> > len)
> >   {
> > +    struct vcpu *current_vcpu = current;
> 
> It is not clear to me what is the perceived side effect here and the others
> below. Can you clarify?

I am guessing that's because current is a global variable? But only
reading (not writing) a global variable should be OK?


  reply	other threads:[~2023-10-19  1:01 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18 14:18 [XEN PATCH 0/4][for-4.19] xen: address violations of Rule 13.1 Simone Ballarin
2023-10-18 14:18 ` [XEN PATCH 1/4] xen/arm: address violations of MISRA C:2012 " Simone Ballarin
2023-10-18 15:03   ` Julien Grall
2023-10-19  1:01     ` Stefano Stabellini [this message]
2023-10-19  7:34     ` Simone Ballarin
2023-10-19  8:19       ` Julien Grall
2023-10-19  8:43         ` Simone Ballarin
2023-10-19 10:11           ` Julien Grall
2023-10-19 11:10             ` Simone Ballarin
2023-10-19 12:30               ` Julien Grall
2023-10-19 13:24                 ` Simone Ballarin
2023-10-19 18:30                   ` Stefano Stabellini
2023-10-20  8:28                     ` Julien Grall
2023-10-23 15:10                       ` Simone Ballarin
2023-10-18 14:18 ` [XEN PATCH 2/4] automation/eclair: add deviations and call properties Simone Ballarin
2023-10-19  0:57   ` Stefano Stabellini
2023-10-19  7:44     ` Simone Ballarin
2023-10-19  8:26       ` Julien Grall
2023-10-19  9:04         ` Simone Ballarin
2023-10-18 14:18 ` [XEN PATCH 3/4] xen/include: add pure and const attributes Simone Ballarin
2023-10-19  1:02   ` Stefano Stabellini
2023-10-19  9:07     ` Simone Ballarin
2023-10-23 13:34   ` Jan Beulich
2023-10-23 13:51     ` Andrew Cooper
2023-10-23 14:09       ` Jan Beulich
2023-10-23 15:23     ` Simone Ballarin
2023-10-23 15:33       ` Jan Beulich
2023-10-23 22:05         ` Stefano Stabellini
2023-10-23 22:12           ` Stefano Stabellini
2023-10-24  6:24           ` Jan Beulich
2024-02-23  1:32             ` Stefano Stabellini
2024-02-23  7:36               ` Jan Beulich
2024-02-23 22:36                 ` Stefano Stabellini
2024-02-26  7:33                   ` Jan Beulich
2024-02-26 23:48                     ` Stefano Stabellini
2024-02-27  7:23                       ` Jan Beulich
2024-02-28  2:14                         ` Stefano Stabellini
2023-10-18 14:18 ` [XEN PATCH 4/4] xen: address violations of MISRA C:2012 Rule 13.1 Simone Ballarin
2023-10-19  1:06   ` Stefano Stabellini
2023-10-19  9:18     ` Simone Ballarin
2023-10-19 18:35       ` Stefano Stabellini
2023-10-19  9:35     ` Jan Beulich
2023-10-19 11:12       ` Simone Ballarin
2023-10-19 11:19         ` Jan Beulich
2023-10-19 13:36           ` Simone Ballarin
2023-10-19 18:35             ` Stefano Stabellini
2023-10-23 14:03   ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.22.394.2310181759310.965337@ubuntu-linux-20-04-desktop \
    --to=sstabellini@kernel.org \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=bertrand.marquis@arm.com \
    --cc=consulting@bugseng.com \
    --cc=julien@xen.org \
    --cc=simone.ballarin@bugseng.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.