All of lore.kernel.org
 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 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.