All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Lieven <pl@kamp.de>
To: qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: kwolf@redhat.com, famz@redhat.com, stefanha@gmail.com,
	jcody@redhat.com, Peter Lieven <pl@kamp.de>,
	jsnow@redhat.com
Subject: [Qemu-devel] [PATCH V4 0/6] ide: avoid main-loop hang on CDROM/NFS failure
Date: Thu, 12 Nov 2015 17:30:40 +0100	[thread overview]
Message-ID: <1447345846-15624-1-git-send-email-pl@kamp.de> (raw)

This series aims at avoiding a hanging main-loop if a vserver has a
CDROM image mounted from a NFS share and that NFS share goes down.
Typical situation is that users mount an CDROM ISO to install something
and then forget to eject that CDROM afterwards.
As a consequence this mounted CD is able to bring down the
whole vserver if the backend NFS share is unreachable. This is bad
especially if the CDROM itself is not needed anymore at this point.

v3->v4: - Patch 1: remove buf argument for cd_read_sector{_sync}
        - Patch 1: fix iov_base offset for 2352 sector size
        - Patch 2: fix indent [Fam]
        - Patch 3: fix leaking of req->iov.iov_base [Fam]

v2->v3: - adressed Stefans comments on Patch 1
        - added patches 2,4,5,6
        - avoided the term cancel in Patch 3. Added an iovec,
          added a BH [Stefan]
v1->v2: - fix offset for 2352 byte sector size [Kevin]
        - use a sync request if we continue an elementary transfer.
          As John pointed out we enter a race condition between next
          IDE command and async transfer otherwise. This is sill not
          optimal, but it fixes the NFS down problems for all cases where
          the NFS server goes down while there is no PIO CD activity.
          Of course, it could still happen during a PIO transfer, but I
          expect this to be the unlikelier case.
          I spent some effort trying to read more sectors at once and
          avoiding continuation of elementary transfers, but with
          whatever I came up it was destroying migration between different
          Qemu versions. I have a quite hackish patch that works and
          should survive migration, but I am not happy with it. So I
          would like to start with this version as it is a big improvement
          already.
        - Dropped Patch 5 because it is upstream meanwhile.

Peter Lieven (6):
  ide/atapi: make PIO read requests async
  block: add blk_abort_aio_request
  ide: add support for IDEBufferedRequest
  ide: orphan all buffered requests on DMA cancel
  ide: enable buffered requests for ATAPI devices
  ide: enable buffered requests for PIO read requests

 block/block-backend.c          |  17 +++----
 hw/ide/atapi.c                 | 103 +++++++++++++++++++++++++++++++++++------
 hw/ide/core.c                  |  51 +++++++++++++++++++-
 hw/ide/internal.h              |  14 ++++++
 hw/ide/pci.c                   |  19 ++++++++
 include/sysemu/block-backend.h |   3 ++
 6 files changed, 182 insertions(+), 25 deletions(-)

-- 
1.9.1

             reply	other threads:[~2015-11-12 16:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-12 16:30 Peter Lieven [this message]
2015-11-12 16:30 ` [Qemu-devel] [PATCH V4 1/6] ide/atapi: make PIO read requests async Peter Lieven
2015-11-13 22:42   ` John Snow
2015-11-13 23:00     ` Peter Lieven
2015-11-12 16:30 ` [Qemu-devel] [PATCH V4 2/6] block: add blk_abort_aio_request Peter Lieven
2015-11-12 16:30 ` [Qemu-devel] [PATCH V4 3/6] ide: add support for IDEBufferedRequest Peter Lieven
2015-11-12 16:30 ` [Qemu-devel] [PATCH V4 4/6] ide: orphan all buffered requests on DMA cancel Peter Lieven
2015-11-12 16:30 ` [Qemu-devel] [PATCH V4 5/6] ide: enable buffered requests for ATAPI devices Peter Lieven
2015-11-12 16:30 ` [Qemu-devel] [PATCH V4 6/6] ide: enable buffered requests for PIO read requests Peter Lieven
2015-11-13 11:13 ` [Qemu-devel] [PATCH V4 0/6] ide: avoid main-loop hang on CDROM/NFS failure Mark Cave-Ayland
2015-11-13 17:18   ` John Snow
2015-11-13 22:44 ` John Snow
2015-11-16  6:17   ` Fam Zheng
2015-11-16  6:48     ` Peter Lieven
2015-11-16 19:24     ` John Snow
2015-11-17  4:17       ` Fam Zheng

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=1447345846-15624-1-git-send-email-pl@kamp.de \
    --to=pl@kamp.de \
    --cc=famz@redhat.com \
    --cc=jcody@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.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.