From: Halil Pasic <pasic@linux.ibm.com>
To: Vineeth Vijayan <vneethv@linux.ibm.com>
Cc: Peter Oberparleiter <oberpar@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Michael Mueller <mimu@linux.ibm.com>,
Cornelia Huck <cohuck@redhat.com>,
Pierre Morel <pmorel@linux.ibm.com>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, bfu@redhat.com,
Halil Pasic <pasic@linux.ibm.com>
Subject: Re: [RFC PATCH 1/1] s390/cio: make ccw_device_dma_* more robust
Date: Tue, 12 Oct 2021 23:32:47 +0200 [thread overview]
Message-ID: <20211012233247.63b7a22c.pasic@linux.ibm.com> (raw)
In-Reply-To: <13162b9e48402f306b3f50e6686d76a051138a75.camel@linux.ibm.com>
On Tue, 12 Oct 2021 15:36:36 +0200
Vineeth Vijayan <vneethv@linux.ibm.com> wrote:
> Looks good. Thanks.
> Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Can I convince you to upgrade to Reviewed-by?
>
> Some minor questions below.
>
> On Mon, 2021-10-11 at 13:59 +0200, Halil Pasic wrote:
> > Since commit 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O
> > and
> > classic notifiers") we were supposed to make sure that
> > virtio_ccw_release_dev() completes before the ccw device and the
> > attached dma pool are torn down, but unfortunately we did
> > not. Before
> > that commit it used to be OK to delay cleaning up the memory
> > allocated
> > by virtio-ccw indefinitely (which isn't really intuitive for guys
> > used
> > to destruction happens in reverse construction order), but now we
> > trigger a BUG_ON if the genpool is destroyed before all memory
> > allocated
> > form it.
> allocated from it ?
Yes. And I think I should add "is deallocated." to the end as well,
because we don't destroy memory, we deallocate it ;)
> > Which brings down the guest. We can observe this problem, when
> > unregister_virtio_device() does not give up the last reference to the
> > virtio_device (e.g. because a virtio-scsi attached scsi disk got
> > removed
> > without previously unmounting its previously mounted partition).
> >
> > To make sure that the genpool is only destroyed after all the
> > necessary
> > freeing is done let us take a reference on the ccw device on each
> > ccw_device_dma_zalloc() and give it up on each ccw_device_dma_free().
> >
> > Actually there are multiple approaches to fixing the problem at hand
> > that can work. The upside of this one is that it is the safest one
> > while
> > remaining simple. We don't crash the guest even if the driver does
> > not
> > pair allocations and frees. The downside is the reference counting
> > overhead, that the reference counting for ccw devices becomes more
> > complex, in a sense that we need to pair the calls to the
> > aforementioned
> > functions for it to be correct, and that if we happen to leak, we
> > leak
> > more than necessary (the whole ccw device instead of just the
> > genpool).
> >
> > Some alternatives to this approach are taking a reference in
> > virtio_ccw_online() and giving it up in virtio_ccw_release_dev() or
> > making sure virtio_ccw_release_dev() completes its work before
> > virtio_ccw_remove() returns. The downside of these approaches is that
> > these are less safe against programming errors.
> >
> > Cc: <stable@vger.kernel.org> # v5.3
> > Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
> > Fixes: 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and
> > classic notifiers")
> > Reported-by: bfu@redhat.com
> >
> > ---
> >
> > FYI I've proposed a different fix to this very same problem:
> > https://lore.kernel.org/lkml/20210915215742.1793314-1-pasic@linux.ibm.com/
> >
> > This patch is more or less a result of that discussion.
> >
>
next prev parent reply other threads:[~2021-10-12 21:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 11:59 [RFC PATCH 1/1] s390/cio: make ccw_device_dma_* more robust Halil Pasic
2021-10-11 13:45 ` Pierre Morel
2021-10-11 14:33 ` Cornelia Huck
2021-10-11 18:48 ` Halil Pasic
2021-10-12 13:50 ` Cornelia Huck
2021-10-12 22:37 ` Halil Pasic
2021-10-13 6:51 ` Cornelia Huck
2021-10-12 14:10 ` Pierre Morel
2021-10-11 18:42 ` Halil Pasic
2021-10-12 13:36 ` Vineeth Vijayan
2021-10-12 21:32 ` Halil Pasic [this message]
2021-10-13 7:29 ` Vineeth Vijayan
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=20211012233247.63b7a22c.pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=bfu@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mimu@linux.ibm.com \
--cc=oberpar@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=vneethv@linux.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.