linux-s390.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	kvm@vger.kernel.org, borntraeger@de.ibm.com,
	pasic@linux.vnet.ibm.com, pmorel@linux.vnet.ibm.com
Subject: Re: [PATCH 2/4] vfio: ccw: refactor and improve pfn_array_alloc_pin()
Date: Tue, 27 Mar 2018 12:01:27 +0200	[thread overview]
Message-ID: <20180327120127.16f7884f.cohuck@redhat.com> (raw)
In-Reply-To: <20180327030026.GI12194@bjsdjshi@linux.vnet.ibm.com>

On Tue, 27 Mar 2018 11:00:26 +0800
Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote:

> * Cornelia Huck <cohuck@redhat.com> [2018-03-26 15:28:46 +0200]:
> 
> > On Wed, 21 Mar 2018 03:08:20 +0100
> > Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote:
> >   
> > > This refactors pfn_array_alloc_pin() and also improves it by adding
> > > defensive code in error handling so that calling pfn_array_unpin_free()
> > > after error return won't lead to problem. This mains does:
> > > 1. Merge pfn_array_pin() into pfn_array_alloc_pin(), since there is no
> > >    other user of pfn_array_pin(). As a result, also remove kernel-doc
> > >    for pfn_array_pin() and add kernel-doc for pfn_array_alloc_pin().
> > > 2. For a vfio_pin_pages() failure, set pa->pa_nr to zero to indicate
> > >    zero pages were pinned.
> > > 3. Set pa->pa_iova_pfn to NULL right after it was freed.
> > > 
> > > Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>
> > > ---
> > >  drivers/s390/cio/vfio_ccw_cp.c | 84 ++++++++++++++++++------------------------
> > >  1 file changed, 36 insertions(+), 48 deletions(-)
> > > 
> > > diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
> > > index 2be114db02f9..3abc9770910a 100644
> > > --- a/drivers/s390/cio/vfio_ccw_cp.c
> > > +++ b/drivers/s390/cio/vfio_ccw_cp.c
> > > @@ -46,65 +46,32 @@ struct ccwchain {
> > >  };
> > >  
> > >  /*
> > > - * pfn_array_pin() - pin user pages in memory
> > > + * pfn_array_alloc_pin() - alloc memory for PFNs, then pin user pages in memory
> > >   * @pa: pfn_array on which to perform the operation
> > >   * @mdev: the mediated device to perform pin/unpin operations
> > > + * @iova: target guest physical address
> > > + * @len: number of bytes that should be pinned from @iova
> > >   *
> > > - * Attempt to pin user pages in memory.
> > > + * Attempt to allocate memory for PFNs, and pin user pages in memory.
> > >   *
> > >   * Usage of pfn_array:
> > > - * @pa->pa_iova     starting guest physical I/O address. Assigned by caller.
> > > + * @pa->pa_iova     starting guest physical I/O address. Assigned by callee.
> > >   * @pa->pa_iova_pfn array that stores PFNs of the pages need to pin. Allocated
> > > - *                  by caller.
> > > + *                  by callee.
> > >   * @pa->pa_pfn      array that receives PFNs of the pages pinned. Allocated by
> > > - *                  caller.
> > > - * @pa->pa_nr       number of pages from @pa->pa_iova to pin. Assigned by
> > > - *                  caller.
> > > - *                  number of pages pinned. Assigned by callee.
> > > + *                  callee.
> > > + * @pa->pa_nr       initiated as 0 by caller.  
> > 
> > s/initiated/initialized/  
> Ok.
> 
> > 
> > but see below
> >   
> > > + *                  number of pages pinned from @pa->pa_iova. Assigned by callee.  
> > 
> > So, basically everything is filled by pfn_array_alloc_pin()?  
> Yes.
> 
> > Should we expect a clean struct pfn_array handed in by the caller,
> > then (not just pa_nr == 0)?  
> The current idea is:
> - It is a clean struct that pfn_array_alloc_pin() expects from its
>   caller.
> - pfn_array_alloc_pin() and pfn_array_unpin_free() should be used in
>   pair. They are the only functions those change the values of the
>   elements of a pfn_array struct.
> - Caller of pfn_array_alloc_pin() should either hand in a new allocated
>   pfn_array (zeroed out), or a freed-after-used one.
> - So using pa_nr == 0, is enough to identify all the good cases.
>   [We set pa_nr to 0 in pfn_array_unpin_free().]
> 
> Validating all of the elements only helps when there is case that a
> caller breaks the usage rule of these interfaces - the caller itself
> assigns values for pfn_pa elements directly... I don't think we allow
> this to happen.
> 
> So I think the current logic is fine.

Yes, I think it is fine -- I was mainly wondering whether we wanted
more sanity checks.

> 
> > 
> > Would it make sense to describe the contents of the struct pfn_array
> > fields at the struct's definition instead? You could then shorten the
> > description here to "we expect pa_nr == 0, any field in this structure
> > will be filled in by this function".  
> Sounds good!
> Do you want a separated patch for this, or I do this change on this
> patch? Either will be ok with me.

Perhaps as an additional patch in front of this one?

  parent reply	other threads:[~2018-03-27 10:01 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21  2:08 [PATCH 0/4] vfio: ccw: error handling fixes and improvements Dong Jia Shi
2018-03-21  2:08 ` [PATCH 1/4] vfio: ccw: fix cleanup if cp_prefetch fails Dong Jia Shi
2018-03-21 12:49   ` Halil Pasic
     [not found]     ` <20180322022248.GB12194@bjsdjshi@linux.vnet.ibm.com>
2018-03-22  9:37       ` Pierre Morel
2018-03-22 10:10         ` Halil Pasic
2018-03-26 12:28         ` Cornelia Huck
     [not found]           ` <20180327014200.GH12194@bjsdjshi@linux.vnet.ibm.com>
2018-04-20 10:54             ` Halil Pasic
2018-04-20 11:36               ` Cornelia Huck
2018-04-20 11:55                 ` Halil Pasic
2018-03-21  2:08 ` [PATCH 2/4] vfio: ccw: refactor and improve pfn_array_alloc_pin() Dong Jia Shi
2018-03-26 13:28   ` Cornelia Huck
     [not found]     ` <20180327030026.GI12194@bjsdjshi@linux.vnet.ibm.com>
2018-03-27 10:01       ` Cornelia Huck [this message]
     [not found]         ` <20180328023638.GL12194@bjsdjshi@linux.vnet.ibm.com>
2018-03-28  7:58           ` Cornelia Huck
2018-03-21  2:08 ` [PATCH 3/4] vfio: ccw: set ccw->cda to NULL defensively Dong Jia Shi
2018-03-26 13:47   ` Cornelia Huck
     [not found]     ` <20180327030809.GJ12194@bjsdjshi@linux.vnet.ibm.com>
2018-03-27 10:03       ` Cornelia Huck
2018-03-21  2:08 ` [PATCH 4/4] vfio: ccw: add traceponits for interesting error paths Dong Jia Shi
2018-03-26 13:59   ` Cornelia Huck
     [not found]     ` <20180327075114.GK12194@bjsdjshi@linux.vnet.ibm.com>
2018-03-27 10:07       ` Cornelia Huck
2018-03-27 15:27         ` Halil Pasic
2018-03-29 12:32           ` Cornelia Huck
     [not found]         ` <20180410021639.GN5428@bjsdjshi@linux.vnet.ibm.com>
2018-04-10  8:55           ` Cornelia Huck
2018-04-10 10:48             ` Halil Pasic
2018-03-26  9:02 ` [PATCH 0/4] vfio: ccw: error handling fixes and improvements Cornelia Huck
2018-03-26 11:25   ` Halil Pasic

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=20180327120127.16f7884f.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=bjsdjshi@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pasic@linux.vnet.ibm.com \
    --cc=pmorel@linux.vnet.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).