mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Li Dongyang <lidongyang@novell.com>,
	"hch@infradead.org" <hch@infradead.org>,
	Dong Yang Li <lidongyang@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] Re: [PATCH 2/3] xen/blkback: Fix the inhibition to map pages when discarding sector ranges.
Date: Wed, 12 Oct 2011 11:30:25 +0100	[thread overview]
Message-ID: <1318415425.21903.652.camel@zakaz.uk.xensource.com> (raw)
In-Reply-To: <20111011205035.GA22668@phenom.oracle.com>

On Tue, 2011-10-11 at 21:50 +0100, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 11, 2011 at 02:39:09PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Oct 11, 2011 at 03:33:11PM +0800, Li Dongyang wrote:
> > > On Tue, Oct 11, 2011 at 3:25 PM, Jan Beulich <JBeulich@suse.com> wrote:
> > > >>>> On 10.10.11 at 17:28, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > > >> The 'operation' parameters are the ones provided to the bio layer while
> > > >> the req->operation are the ones passed in between the backend and
> > > >> frontend. We used the wrong 'operation' value to squash the
> > > >> call to map pages when processing the discard operation resulting
> > > >> in mapping the pages unnecessarily.
> > > >>
> > > >> CC: Li Dongyang <lidongyang@novell.com>
> > > >> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > >> ---
> > > >>  drivers/block/xen-blkback/blkback.c |    2 +-
> > > >>  1 files changed, 1 insertions(+), 1 deletions(-)
> > > >>
> > > >> diff --git a/drivers/block/xen-blkback/blkback.c
> > > >> b/drivers/block/xen-blkback/blkback.c
> > > >> index 184b133..3da9a40 100644
> > > >> --- a/drivers/block/xen-blkback/blkback.c
> > > >> +++ b/drivers/block/xen-blkback/blkback.c
> > > >> @@ -707,7 +707,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
> > > >>        * the hypercall to unmap the grants - that is all done in
> > > >>        * xen_blkbk_unmap.
> > > >>        */
> > > >> -     if (operation != BLKIF_OP_DISCARD &&
> > > >> +     if (operation != REQ_DISCARD &&
> > > >
> > > > Why is that check necessary in the first place? xen_blkbk_map() doesn't
> > > > do any harm when req->nr_segments is zero (as could also be the case
> > > > on WRITE_FLUSH ones).
> > > >
> > > Ah, you are right, we could remove this check then, Thanks
> > 
> > Except that req->nr_segments for blkif__request_discard is actually
> > the reserved field.

Either this field is nr_segments for op==DISCARD or it is not.

If it is then it should be named nr_segments and treated as such.

If it is not then it is a bug for anything to look at those bits in
memory and treat them as nr_segments.

There was a patch (from Own Smith) at one point to use a union in the
blkif request data type, would doing that help to make it clear which
fields overlap and which do not?

> > See:
> > 
> > struct blkif_request {
> >     uint8_t        operation;    /* BLKIF_OP_???                         */
> >     uint8_t        nr_segments;  /* number of segments                   */
> >     blkif_vdev_t   handle;       /* only for read/write requests         */
> > .. snip..
> > 
> > and:
> > struct blkif_request_discard {
> >     uint8_t        operation;    /* BLKIF_OP_DISCARD                     */
> >                                  /* ignored if 'discard-secure=0'        */
> > #define BLKIF_OP_DISCARD_FLAG_SECURE (1<<0)
> >     uint8_t        flag;         /* BLKIF_OP_DISCARD_FLAG_SECURE or 0    */
> >     blkif_vdev_t   handle;       /* same as for read/write requests      */
> > 
> > which will throw off the logic for nr_segments all wrong since for some
> > discard operations it would read the nr_segments as 1.

> > 
> > So we do need some logic in there to work with this.
> 
> 
> So a patch like this (and there is another on top that moves the setting
> of nseg) should do it.
> 
> 
> commit 12679b29b2f828454f833e17e9090ed576c63afc
> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date:   Mon Oct 10 00:47:49 2011 -0400
> 
>     xen/blkback: Fix the inhibition to map pages when discarding sector ranges.
>     
>     The 'operation' parameters are the ones provided to the bio layer while
>     the req->operation are the ones passed in between the backend and
>     frontend. We used the wrong 'operation' value to squash the
>     call to map pages when processing the discard operation resulting
>     in an hypercall that did nothing. Lets guard against going in the
>     mapping function by checking for the amount of segments.
>     
>     CC: Li Dongyang <lidongyang@novell.com>
>     Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c
> index c15c559..94e659d 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -707,8 +707,7 @@ static int dispatch_rw_block_io(struct xen_blkif *blkif,
>  	 * the hypercall to unmap the grants - that is all done in
>  	 * xen_blkbk_unmap.
>  	 */
> -	if (operation != BLKIF_OP_DISCARD &&
> -			xen_blkbk_map(req, pending_req, seg))
> +	if (nseg && xen_blkbk_map(req, pending_req, seg))

nseg == reg->nr_segments, so as above either referencing nseg when
operation == BLKIF_OP_DISCARD is a bug or the field is badly named.

Ian.

>  		goto fail_flush;
>  
>  	/*
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



  parent reply	other threads:[~2011-10-12 10:30 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-10 15:28 [PATCH] Xen block fixes, secure discard, and barrier support for 3.2 (v1) Konrad Rzeszutek Wilk
2011-10-10 15:28 ` [PATCH 1/3] xen/blkback: Support 'feature-barrier' aka old-style BARRIER requests Konrad Rzeszutek Wilk
2011-10-17 11:36   ` Jan Beulich
2011-10-17 16:50     ` Konrad Rzeszutek Wilk
2011-10-17 12:27   ` Jan Beulich
2011-10-17 16:52     ` Konrad Rzeszutek Wilk
2011-10-10 15:28 ` [PATCH 2/3] xen/blkback: Fix the inhibition to map pages when discarding sector ranges Konrad Rzeszutek Wilk
2011-10-11  7:25   ` Jan Beulich
     [not found]   ` <4E940B99020000780005AA12@victor.provo.novell.com>
2011-10-11  7:33     ` Li Dongyang
2011-10-11 18:39       ` [Xen-devel] " Konrad Rzeszutek Wilk
2011-10-11 20:50         ` Konrad Rzeszutek Wilk
2011-10-12 10:18           ` Jan Beulich
2011-10-12 10:30           ` Ian Campbell [this message]
2011-10-10 15:28 ` [PATCH 3/3] xen/blk[front|back]: Enhance discard support with secure erasing support Konrad Rzeszutek Wilk
2011-10-10 16:13   ` [Xen-devel] " Ian Campbell
2011-10-10 16:42     ` Konrad Rzeszutek Wilk
2011-10-10 17:53       ` Konrad Rzeszutek Wilk
2011-10-10 19:19         ` Ian Campbell
2011-10-10 19:20       ` Ian Campbell
2011-10-10 19:57         ` Konrad Rzeszutek Wilk
2011-10-11  7:36           ` Jan Beulich
2011-10-11  8:09             ` Ian Campbell
2011-10-11 15:51             ` Konrad Rzeszutek Wilk
2011-10-11 20:57               ` Konrad Rzeszutek Wilk
2011-10-12 10:54                 ` Ian Campbell
2011-10-12 15:45                   ` Konrad Rzeszutek Wilk
2011-10-12 16:14                     ` Ian Campbell
2011-10-12 17:21                       ` Konrad Rzeszutek Wilk
2011-10-17 13:23                 ` Jan Beulich
2011-10-21  0:06                   ` Konrad Rzeszutek Wilk
     [not found]                 ` <4E9C4855020000780005BA73@victor.provo.novell.com>
2011-10-20  3:17                   ` Li Dongyang
2011-10-20  3:46                     ` Konrad Rzeszutek Wilk

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=1318415425.21903.652.camel@zakaz.uk.xensource.com \
    --to=ian.campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=hch@infradead.org \
    --cc=konrad.wilk@oracle.com \
    --cc=lidongyang@novell.com \
    --cc=lidongyang@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xen-devel@lists.xensource.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

all inboxes | Powered by JetHome®