All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Quan Xu <quan.xu@intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Keir Fraser <keir@xen.org>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	dario.faggioli@citrix.com, xen-devel@lists.xen.org,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [PATCH v5 03/10] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping
Date: Mon, 23 May 2016 08:19:04 -0600	[thread overview]
Message-ID: <57432D7802000078000EDE6D@prv-mh.provo.novell.com> (raw)
In-Reply-To: <1463558911-98187-4-git-send-email-quan.xu@intel.com>

>>> On 18.05.16 at 10:08, <quan.xu@intel.com> wrote:

> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -2463,11 +2463,12 @@ static int __put_page_type(struct page_info *page,
>  }
>  
>  
> -static int __get_page_type(struct page_info *page, unsigned long type,
> -                           int preemptible)
> +static int __must_check __get_page_type(struct page_info *page,

Such a __must_check is relatively pointless when all existing callers
already check the return value (and surely all code inside mm.c
knows it needs to), and you don't at the same time make the
non-static functions propagating its return value also __must_check.
Hence I think best is to limit your effort to IOMMU functions for this
patch set.

> +                                        unsigned long type,
> +                                        int preemptible)
>  {
>      unsigned long nx, x, y = page->u.inuse.type_info;
> -    int rc = 0;
> +    int rc = 0, ret = 0;
>  
>      ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
>  
> @@ -2578,11 +2579,11 @@ static int __get_page_type(struct page_info *page, unsigned long type,
>          if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
>          {
>              if ( (x & PGT_type_mask) == PGT_writable_page )
> -                iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
> +                ret = iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
>              else if ( type == PGT_writable_page )
> -                iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
> -                               page_to_mfn(page),
> -                               IOMMUF_readable|IOMMUF_writable);
> +                ret = iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
> +                                     page_to_mfn(page),
> +                                     IOMMUF_readable|IOMMUF_writable);
>          }
>      }
>  
> @@ -2599,6 +2600,9 @@ static int __get_page_type(struct page_info *page, unsigned long type,
>      if ( (x & PGT_partial) && !(nx & PGT_partial) )
>          put_page(page);
>  
> +    if ( !rc )
> +        rc = ret;

I know I've seen this a couple of time already, but with the special
purpose of "ret" I really wonder whether a more specific name
wouldn't be warranted - e.g. "iommu_rc" or "iommu_ret".

> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -658,7 +658,7 @@ bool_t ept_handle_misconfig(uint64_t gpa)
>   *
>   * Returns: 0 for success, -errno for failure
>   */
> -static int
> +static int __must_check
>  ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn, 

Now adding the annotation here, without also (first) adding it to
the p2m method which this gets used for (and which is this function's
sole purpose), is not useful at all. Please remember - we don't want
this annotation because it looks good, but in order to make sure
errors don't get wrongly ignored. That's why, from the beginning, I
have been telling you that adding such annotations to other than
new code means doing it top down (which you clearly don't do here).

> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -171,20 +171,33 @@ void __hwdom_init iommu_hwdom_init(struct domain *d)
>      {
>          struct page_info *page;
>          unsigned int i = 0;
> +        int rc = 0;
> +
>          page_list_for_each ( page, &d->page_list )
>          {
>              unsigned long mfn = page_to_mfn(page);
>              unsigned long gfn = mfn_to_gmfn(d, mfn);
>              unsigned int mapping = IOMMUF_readable;
> +            int ret;
>  
>              if ( ((page->u.inuse.type_info & PGT_count_mask) == 0) ||
>                   ((page->u.inuse.type_info & PGT_type_mask)
>                    == PGT_writable_page) )
>                  mapping |= IOMMUF_writable;
> -            hd->platform_ops->map_page(d, gfn, mfn, mapping);
> +
> +            ret = hd->platform_ops->map_page(d, gfn, mfn, mapping);
> +
> +            if ( unlikely(ret) )
> +                rc = ret;

This should be good enough, but I think it would be better if, just
like elsewhere, you returned the first error instead of the last one.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-05-23 14:19 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-18  8:08 [PATCH v5 00/10] Check VT-d Device-TLB flush error Quan Xu
2016-05-18  8:08 ` [PATCH v5 01/10] vt-d: fix the IOMMU flush issue Quan Xu
2016-05-23 13:30   ` Jan Beulich
2016-05-23 15:22     ` Xu, Quan
2016-05-23 15:43       ` Jan Beulich
2016-05-25  8:04         ` Xu, Quan
2016-05-25  8:29           ` Jan Beulich
2016-05-25  8:53             ` Xu, Quan
2016-05-26 10:37             ` Xu, Quan
2016-05-26 14:37               ` Xu, Quan
2016-05-26 15:56               ` Jan Beulich
2016-05-26 16:20                 ` Xu, Quan
2016-05-26  6:20     ` Xu, Quan
2016-05-18  8:08 ` [PATCH v5 02/10] IOMMU: handle IOMMU mapping and unmapping failures Quan Xu
2016-05-23 13:40   ` Jan Beulich
2016-05-24  9:09     ` Xu, Quan
2016-05-18  8:08 ` [PATCH v5 03/10] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping Quan Xu
2016-05-23 14:19   ` Jan Beulich [this message]
2016-05-25 15:34     ` Xu, Quan
2016-05-25 16:01       ` Jan Beulich
2016-05-26  1:42         ` Xu, Quan
2016-05-26 15:49           ` Jan Beulich
2016-05-18  8:08 ` [PATCH v5 04/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU unmapping Quan Xu
2016-05-18  8:08 ` [PATCH v5 05/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping Quan Xu
2016-05-23 15:53   ` Jan Beulich
2016-05-24  9:01     ` Xu, Quan
2016-05-24  9:09       ` Jan Beulich
2016-05-24  9:14         ` Xu, Quan
2016-05-18  8:08 ` [PATCH v5 06/10] IOMMU/MMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (top level ones) Quan Xu
2016-05-23 16:05   ` Jan Beulich
2016-05-24  1:16     ` Xu, Quan
2016-05-24  7:01       ` Jan Beulich
2016-05-24  7:08         ` Tian, Kevin
2016-05-24  8:11           ` Xu, Quan
2016-05-24  8:34             ` Jan Beulich
2016-05-24  8:44               ` Xu, Quan
2016-05-18  8:08 ` [PATCH v5 07/10] IOMMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (leaf ones) Quan Xu
2016-05-24  3:42   ` Xu, Quan
2016-05-24  7:52     ` Jan Beulich
2016-05-18  8:08 ` [PATCH v5 08/10] vt-d/ept: propagate IOMMU Device-TLB flush error up to EPT update Quan Xu
2016-05-24  7:58   ` Jan Beulich
2016-05-18  8:08 ` [PATCH v5 09/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending Quan Xu
2016-05-24  8:21   ` Jan Beulich
2016-05-25  6:41     ` Xu, Quan
2016-05-25  8:06       ` Jan Beulich
2016-05-25 15:13         ` Xu, Quan
2016-05-18  8:08 ` [PATCH v5 10/10] vt-d: propagate error up to ME phantom function mapping and unmapping Quan Xu
2016-05-24  8:28   ` Jan Beulich
2016-05-18 10:20 ` [PATCH v5 00/10] Check VT-d Device-TLB flush error Jan Beulich
2016-05-18 12:13   ` Xu, Quan

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=57432D7802000078000EDE6D@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=jun.nakajima@intel.com \
    --cc=keir@xen.org \
    --cc=kevin.tian@intel.com \
    --cc=quan.xu@intel.com \
    --cc=xen-devel@lists.xen.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.