similar to: [PATCH] Fix uninitialized variable in efi

cleanup all resource allocated by virtio_mmio_probe. Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> --- drivers/virtio/virtio_mmio.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c index 74dc717..3fd0e66 100644 --- a/drivers/virtio/virtio_mmio.c +++

cleanup all resource allocated by virtio_mmio_probe. Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> --- drivers/virtio/virtio_mmio.c | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c index 74dc717..3fd0e66 100644 --- a/drivers/virtio/virtio_mmio.c +++

On Sat, 2 Dec 2017 01:51:40 +0800 weiping zhang <zwp10758 at gmail.com> wrote: > cleanup all resource allocated by virtio_mmio_probe. > > Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> > --- > drivers/virtio/virtio_mmio.c | 34 ++++++++++++++++++++++++++-------- > 1 file changed, 26 insertions(+), 8 deletions(-) > > diff --git

As mentioned at drivers/base/core.c: /* * NOTE: _Never_ directly free @dev after calling this function, even * if it returned an error! Always use put_device() to give up the * reference initialized in this function instead. */ Normal we do cleanup for @vm_dev by contianer_of(@dev), but in this case we need release @mem resource from @pdev and vm_dev->base. It make

As mentioned at drivers/base/core.c: /* * NOTE: _Never_ directly free @dev after calling this function, even * if it returned an error! Always use put_device() to give up the * reference initialized in this function instead. */ so we don't free vm_dev until vm_dev.dev.release be called. Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> --- drivers/virtio/virtio_mmio.c

On Tue, 12 Dec 2017 12:53:02 +0000 Mark Rutland <mark.rutland at arm.com> wrote: > Recent rework of the virtio_mmio probe path balanced a devm_ioremap() > with an iounmap() rather than its devm variant. This ends up corrupting > the devm datastructures, and results in the following boot failure on > arm64 under QEMU 2.9.0: > > [ 3.450397] ------------[ cut here

For whatever reasons SH has highmem bits all over the place but does not enable it via Kconfig. Remove the bitrot. Signed-off-by: Thomas Gleixner <tglx at linutronix.de> --- arch/sh/include/asm/fixmap.h | 8 -------- arch/sh/include/asm/kmap_types.h | 15 --------------- arch/sh/mm/init.c | 8 -------- 3 files changed, 31 deletions(-) ---

On Fri, 5 Apr 2019 01:16:13 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > On s390 protected virtualization guests also have to use bounce I/O > buffers. That requires some plumbing. > > Let us make sure any device using DMA API accordingly is spared from the > problems that hypervisor attempting I/O to a non-shared secure page would > bring. I have problems

On Wed, Apr 22, 2020 at 06:33:13PM -0700, Bo Gan wrote: > On 4/15/20 8:53 AM, Joerg Roedel wrote: > > Hi Mike, > > > > On Tue, Apr 14, 2020 at 07:03:44PM +0000, Mike Stunes wrote: > > > set_memory_decrypted needs to check the return value. I see it > > > consistently return ENOMEM. I've traced that back to split_large_page > > > in

2017-12-12 21:45 GMT+08:00 Mark Rutland <mark.rutland at arm.com>: > Recent rework of the virtio_mmio probe/remove paths balanced a > devm_ioremap() with an iounmap() rather than its devm variant. This ends > up corrupting the devm datastructures, and results in the following > boot-time splat on arm64 under QEMU 2.9.0: > > [ 3.450397] ------------[ cut here

On s390, protected virtualization guests have to use bounced I/O buffers. That requires some plumbing. Let us make sure, any device that uses DMA API with direct ops correctly is spared from the problems, that a hypervisor attempting I/O to a non-shared page would bring. Signed-off-by: Halil Pasic <pasic at linux.ibm.com> --- arch/s390/Kconfig | 4 +++

On s390, protected virtualization guests have to use bounced I/O buffers. That requires some plumbing. Let us make sure, any device that uses DMA API with direct ops correctly is spared from the problems, that a hypervisor attempting I/O to a non-shared page would bring. Signed-off-by: Halil Pasic <pasic at linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda at linux.ibm.com> ---

On s390, protected virtualization guests have to use bounced I/O buffers. That requires some plumbing. Let us make sure, any device that uses DMA API with direct ops correctly is spared from the problems, that a hypervisor attempting I/O to a non-shared page would bring. Signed-off-by: Halil Pasic <pasic at linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda at linux.ibm.com> ---

From: Matt Fleming <matt.fleming at intel.com> The location of __file_info[] and ansicon_counter are split between the core and ldlinux.c32. We can end up calling __ansicon_close (from fp->oop->close) in the process of reloading ldlinux.c32, and while ansicon_counter is set to its initialised data value of 0 when reloading ldlinux.c32, the core is never reloaded, and so __file_info[]

From: Halil Pasic <pasic at linux.ibm.com> On s390, protected virtualization guests have to use bounced I/O buffers. That requires some plumbing. Let us make sure, any device that uses DMA API with direct ops correctly is spared from the problems, that a hypervisor attempting I/O to a non-shared page would bring. Signed-off-by: Halil Pasic <pasic at linux.ibm.com> Reviewed-by:

From: Halil Pasic <pasic at linux.ibm.com> On s390, protected virtualization guests have to use bounced I/O buffers. That requires some plumbing. Let us make sure, any device that uses DMA API with direct ops correctly is spared from the problems, that a hypervisor attempting I/O to a non-shared page would bring. Signed-off-by: Halil Pasic <pasic at linux.ibm.com> Reviewed-by:

Recent rework of the virtio_mmio probe path balanced a devm_ioremap() with an iounmap() rather than its devm variant. This ends up corrupting the devm datastructures, and results in the following boot failure on arm64 under QEMU 2.9.0: [ 3.450397] ------------[ cut here ]------------ [ 3.453822] Trying to vfree() nonexistent vm area (00000000c05b4844) [ 3.460534] WARNING: CPU: 1 PID: 1

Recent rework of the virtio_mmio probe path balanced a devm_ioremap() with an iounmap() rather than its devm variant. This ends up corrupting the devm datastructures, and results in the following boot failure on arm64 under QEMU 2.9.0: [ 3.450397] ------------[ cut here ]------------ [ 3.453822] Trying to vfree() nonexistent vm area (00000000c05b4844) [ 3.460534] WARNING: CPU: 1 PID: 1

On Tue, 9 Apr 2019 12:54:16 +0200 Halil Pasic <pasic at linux.ibm.com> wrote: > On Tue, 9 Apr 2019 12:16:47 +0200 > Cornelia Huck <cohuck at redhat.com> wrote: > > > On Fri, 5 Apr 2019 01:16:13 +0200 > > Halil Pasic <pasic at linux.ibm.com> wrote: > > > > > On s390 protected virtualization guests also have to use bounce I/O > > >

On Wed, 8 May 2019 15:15:40 +0200 Claudio Imbrenda <imbrenda at linux.ibm.com> wrote: > On Fri, 26 Apr 2019 20:32:39 +0200 > Halil Pasic <pasic at linux.ibm.com> wrote: > > > On s390, protected virtualization guests have to use bounced I/O > > buffers. That requires some plumbing. > > > > Let us make sure, any device that uses DMA API with direct