From: Amol Surati <suratiamol@gmail.com>
To: John Snow <jsnow@redhat.com>
Cc: Amol Surati <suratiamol@gmail.com>,
qemu-devel@nongnu.org, "open list:IDE" <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 1/2] ide/hw/core: fix crash on processing a partial-sector-size DMA xfer
Date: Tue, 26 Jun 2018 07:00:52 +0530 [thread overview]
Message-ID: <20180626013050.GA13519@arch> (raw)
In-Reply-To: <4049a376-e991-91ab-a1ea-037ee7c0a5b5@redhat.com>
On Mon, Jun 25, 2018 at 05:10:23PM -0400, John Snow wrote:
>
>
> On 06/20/2018 12:29 AM, Amol Surati wrote:
> > Fixes: https://bugs.launchpad.net/qemu/+bug/1777315
> >
> > QEMU's short PRD policy applies to a DMA transfer of size < 512 bytes.
> > But it fails to consider transfers which are >= 512 bytes, but are
> > not a multiple of 512 bytes.
> >
> > Such transfers are not subject to the short PRD policy. They end up
> > violating the assumptions about the granularity of the IO sizes,
> > upon which depend the verification of the completion of the previous
> > transfer, and the advancement of the offset in preparation of the next.
> >
> > Those violations result in the crash.
> >
> > By forcing each transfer to be a multiple of sector size, such
> > transfers are subjected to the policy, and therefore culled before they
> > cause the crash.
> >
>
> So now even if the PRDT we get is greater than a sector is not an even
> multiple of 512, we reject it as too short.
Yes.
When PRDT is greater than a sector but non an even multiple of 512,
we used to crash. Now we do not.
The reason for this patch is to maintain backward compatibility with the
current split-completion design that QEMU adopts, while still avoiding the
crash. The cover letter has the reasons for this patch.
>
> That doesn't seem correct to me.
https://github.com/asurati/1777315/blob/master/v2.diff has a different
patch, which aligns with what Kevin had suggested. It allows the
IO which you described above, but then it completes the command
as soon as it detects a partial transfer which is larger than 512.
The patch where s->sg.size is used as the offset to start the next
IO would require the dma IOs to be misaligned and of non-512 sizes.
Will that be okay?
Else, one needs to change each implementation
of prepare_buf to ensure that it always ALIGNS_UP to the sector
size any partial read/write/trim, in anticipation of the next PRDT
which can cover the difference.
>
> > Signed-off-by: Amol Surati <suratiamol@gmail.com>
> > ---
> > hw/ide/core.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/ide/core.c b/hw/ide/core.c
> > index 2c62efc536..14d135224b 100644
> > --- a/hw/ide/core.c
> > +++ b/hw/ide/core.c
> > @@ -836,6 +836,7 @@ static void ide_dma_cb(void *opaque, int ret)
> > {
> > IDEState *s = opaque;
> > int n;
> > + int32_t size_prepared;
> > int64_t sector_num;
> > uint64_t offset;
> > bool stay_active = false;
> > @@ -886,7 +887,9 @@ static void ide_dma_cb(void *opaque, int ret)
> > n = s->nsector;
> > s->io_buffer_index = 0;
> > s->io_buffer_size = n * 512;
> > - if (s->bus->dma->ops->prepare_buf(s->bus->dma, s->io_buffer_size) < 512) {
> > + size_prepared = s->bus->dma->ops->prepare_buf(s->bus->dma,
> > + s->io_buffer_size);
> > + if (size_prepared <= 0 || size_prepared % 512) {
> > /* The PRDs were too short. Reset the Active bit, but don't raise an
> > * interrupt. */
> > s->status = READY_STAT | SEEK_STAT;
> >
>
> --
> —js
next prev parent reply other threads:[~2018-06-26 1:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 4:29 [Qemu-devel] [PATCH 0/2] ide/hw/core: fix bug# 1777315, crash on short PRDs Amol Surati
2018-06-20 4:29 ` [Qemu-devel] [PATCH 1/2] ide/hw/core: fix crash on processing a partial-sector-size DMA xfer Amol Surati
2018-06-25 21:10 ` John Snow
2018-06-26 1:30 ` Amol Surati [this message]
2018-06-20 4:29 ` [Qemu-devel] [PATCH 2/2] tests/ide-test: test case for crash when processing short PRDs Amol Surati
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=20180626013050.GA13519@arch \
--to=suratiamol@gmail.com \
--cc=jsnow@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.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.