From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Li Dongyang <lidongyang@novell.com>
Cc: Jan Beulich <JBeulich@suse.com>,
hch@infradead.org, Dong Yang Li <lidongyang@suse.com>,
xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Re: [PATCH 2/3] xen/blkback: Fix the inhibition to map pages when discarding sector ranges.
Date: Tue, 11 Oct 2011 14:39:09 -0400 [thread overview]
Message-ID: <20111011183909.GA2357@phenom.oracle.com> (raw)
In-Reply-To: <CAKH3R4-HJZBE-yWk=Dwkuwy13z1vdUrgEoJ9zFhTJgXgYfHHfA@mail.gmail.com>
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.
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.
next prev parent reply other threads:[~2011-10-11 18:46 UTC|newest]
Thread overview: 39+ 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 11:36 ` Jan Beulich
2011-10-17 16:50 ` Konrad Rzeszutek Wilk
2011-10-17 12:27 ` Jan Beulich
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-10 15:28 ` Konrad Rzeszutek Wilk
2011-10-11 7:25 ` Jan Beulich
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 ` Konrad Rzeszutek Wilk [this message]
2011-10-11 20:50 ` [Xen-devel] " Konrad Rzeszutek Wilk
2011-10-12 10:18 ` Jan Beulich
2011-10-12 10:18 ` Jan Beulich
2011-10-12 10:30 ` Ian Campbell
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 7:36 ` Jan Beulich
2011-10-11 8:09 ` [Xen-devel] " 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-17 13:23 ` Jan Beulich
2011-10-21 0:06 ` [Xen-devel] " 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=20111011183909.GA2357@phenom.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=hch@infradead.org \
--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 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.