similar to: [PATCH] drm/nouveau/bios: fix incorrect kfree in platform_init

(re-sending as plain text) NACK. The before and after of this patch are functionally identical. The if-block returns unconditionally ("return priv;"), so the kfree will only ever be reached if the condition in the if-statement evaluates to false. Explicitly writing out an else-block is thus superfluous. Op 03-01-2020 om 09:10 schreef wuxu.wu: > Hi, I think there has a incorrect

priv porinter could be free only when priv != null and priv->rom is null. Signed-off-by: wuxu.wu <wuxu.wu at huawei.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c index 9b91da0..d776e01 100644 ---

priv porinter could be free only when priv != null and priv->rom is null. --- drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c index 9b91da0..d776e01 100644 ---

On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems, attempting to load the radeon module on a x86_32 kernel can result in the following: BUG: unable to handle page

[AMD Public Use] > -----Original Message----- > From: Bjorn Helgaas <helgaas at kernel.org> > Sent: Saturday, March 28, 2020 4:19 PM > To: Mikel Rychliski <mikel at mikelr.com> > Cc: amd-gfx at lists.freedesktop.org; linux-pci at vger.kernel.org; > nouveau at lists.freedesktop.org; Deucher, Alexander > <Alexander.Deucher at amd.com>; Koenig, Christian >

From: Mikel Rychliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems,

From: Mikel Rychliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems,

From: Mikel Rychliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems,

From: Mikel Rychliski <mikel at mikelr.com> [ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ] On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems,

On Wed, Mar 18, 2020 at 10:16:23PM -0400, Mikel Rychliski wrote: > On some EFI systems, the video BIOS is provided by the EFI firmware. The > boot stub code stores the physical address of the ROM image in pdev->rom. > Currently we attempt to access this pointer using phys_to_virt(), which > doesn't work with CONFIG_HIGHMEM. > > On these systems, attempting to load the

This patch series fixes an oops when loading the radeon driver on old Macs with a 32-bit EFI implementation. Tested on a MacPro 1,1 with a Radeon X1900 XT card and 32-bit kernel. Mikel Rychliski (2): drm/radeon: Stop directly referencing iomem PCI: Use ioremap(), not phys_to_virt() for platform ROM drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 1 +

This patch series fixes an oops when loading the radeon driver on old Macs with a 32-bit EFI implementation. Tested on a MacPro 1,1 with a Radeon X1900 XT card and 32-bit kernel. Changes in v2: - Add iounmap() call in nouveau - Update function comment for pci_platform_rom() - Minor changes to commit messages Mikel Rychliski (2): drm/radeon: Stop directly referencing iomem PCI: Use

On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt(), which doesn't work with CONFIG_HIGHMEM. On these systems, attempting to load the radeon module on a x86_32 kernel can result in the following: BUG: unable to handle page

On Fri, Mar 13, 2020 at 06:22:58PM -0400, Mikel Rychliski wrote: > /** > + * pci_platform_rom - ioremap() the ROM image provided by the platform > * @pdev: pointer to pci device struct > * @size: pointer to receive size of pci window over ROM > + * > + * Return: kernel virtual pointer to image of ROM > + * > + * The caller is responsible for removing the mapping with

> ? to fix it. I suggest to replace this wording by the tag ?Fixes?. ? > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c > @@ -276,8 +276,10 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 flags, > break; > } > > - if (WARN_ON(pi < 0)) > + if (WARN_ON(pi < 0)) { > + kfree(nvbo); > return ERR_PTR(-EINVAL); > + } I propose to

nouveau_bo_alloc() misses to call kfree() in an error path. Add the missed function call to fix it. Signed-off-by: Jing Xiangfeng <jingxiangfeng at huawei.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index c40f127de3d0..abd80b1a6de3 100644 ---

don't free vp_dev until vp_dev->vdev.dev.release be called. Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> --- drivers/virtio/virtio_pci_common.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/virtio/virtio_pci_common.c b/drivers/virtio/virtio_pci_common.c index 1c4797e..91d20f7 100644 ---

don't free vp_vdev until vp_vdev.dev.release be called. Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> --- drivers/misc/mic/vop/vop_main.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/misc/mic/vop/vop_main.c b/drivers/misc/mic/vop/vop_main.c index a341938..8c716a0 100644 --- a/drivers/misc/mic/vop/vop_main.c +++

On Mon, 11 Dec 2017 23:55:16 +0800 weiping zhang <zhangweiping at didichuxing.com> wrote: > don't free vp_dev until vp_dev->vdev.dev.release be called. Maybe add the same description as in your virtio_mmio patch so that it is clear why the kfree() is not ok? > > Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> > --- >

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 vp_vdev until vp_vdev.dev.release be called. Signed-off-by: weiping zhang <zhangweiping at didichuxing.com> ---