search for: ioremap

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 iounmap() &...

is_local_lowmem() treats its physical address input as a machine address; this causes agpgart to fail while calling ioremap_nocache(). X still does not load on my Athlon 64 / Via S3 Unichrome, so perhaps best not to apply just yet. Signed-off-by: Avi Kivity <avi@qumranet.com> --- xen-ioremap-fix/linux-2.6-xen-sparse/arch/i386/mm/ioremap-xen.c~ioremap 2006-06-22 20:30:20.000000000 +0300 +++ xen-ioremap-fix/linu...

...b/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-mm-for-linus Andres Salomon (1): x86, mm: Create symbolic index into address_markers array Borislav Petkov (1): x86, tlb: Clean up and correct used type Florian Zumbiehl (1): x86, iomap: Fix wrong page aligned size calculation in ioremapping code Jiri Slaby (1): x86-64, mm: Initialize VDSO earlier on 64 bits Kenji Kaneshige (2): x86, ioremap: Fix incorrect physical address handling in PAE mode x86, ioremap: Fix normal ram range check Marcin Slusarz (1): x86, kmmio/mmiotrace: Fix double free of kmmio_fault...

...t patch really need to be folded into the previous > one to avoid regressions (assuming my other suggestion doesn't work > for some reason). Addressed in v2 On Tuesday, March 17, 2020 10:47:31 AM EDT Christoph Hellwig wrote: > What is the value of this helper over just open coding an ioremap > of pdev->rom in the callers? I think the direct access to pdev->rom you suggest makes sense, especially because users of the pci_platform_rom() are exposed to the fact that it just calls ioremap(). I decided against wrapping the iounmap() with a pci_unmap_platform_rom(), but I didn&...

...re Duo processor based board. It has 1 GB of physical memory. I have a driver which uses the memory reserved at the top of the high memory. Well this driver worked fine on all the previous versions of RHEL/FC and also with RHEL 5 with virtualization disabled. But with virtualization enabled , the ioremap to the memory reserved at the top of high mem( usin highmem command line option) fails. On digging into the kernel code, I found out that the check if the memory address which I am passing to the ioremap is falling in the low memory region is failing. I rechecked if this is the case by printing the...

...ent); struct nouveau_bar *bar; + bool has_bar3 = nv_device_resource_len(device, 3) != 0; int ret; ret = nouveau_subdev_create_(parent, engine, oclass, 0, "BARCTL", @@ -118,8 +119,10 @@ nouveau_bar_create_(struct nouveau_object *parent, if (ret) return ret; - bar->iomem = ioremap(nv_device_resource_start(device, 3), - nv_device_resource_len(device, 3)); + if (has_bar3) + bar->iomem = ioremap(nv_device_resource_start(device, 3), + nv_device_resource_len(device, 3)); + return 0; } -- 1.8.5.3

...ent); struct nouveau_bar *bar; + bool has_bar3 = nv_device_resource_len(device, 3) != 0; int ret; ret = nouveau_subdev_create_(parent, engine, oclass, 0, "BARCTL", @@ -118,8 +119,10 @@ nouveau_bar_create_(struct nouveau_object *parent, if (ret) return ret; - bar->iomem = ioremap(nv_device_resource_start(device, 3), - nv_device_resource_len(device, 3)); + if (has_bar3) + bar->iomem = ioremap(nv_device_resource_start(device, 3), + nv_device_resource_len(device, 3)); + return 0; } -- 1.9.1

.../drm/nouveau/core/subdev/bar/base.c index bdf594116f3f..73b1ed20c8d5 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/bar/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/bar/base.c @@ -118,8 +118,10 @@ nouveau_bar_create_(struct nouveau_object *parent, if (ret) return ret; - bar->iomem = ioremap(nv_device_resource_start(device, 3), - nv_device_resource_len(device, 3)); + if (nv_device_resource_len(device, 3) != 0) + bar->iomem = ioremap(nv_device_resource_start(device, 3), + nv_device_resource_len(device, 3)); + return 0; } -- 1.9.2

...0x25/0x30 ? __vunmap+0x206/0x230 ? kmem_cache_alloc_trace+0x16f/0x220 ? do_init_module+0x21/0x220 do_init_module+0x50/0x220 load_module+0x1f26/0x2200 sys_init_module+0x12d/0x160 do_fast_syscall_32+0x82/0x250 entry_SYSENTER_32+0xa5/0xf8 Fix the issue by using ioremap() instead of phys_to_virt() in pci_platform_rom(). Now that pci_platform_rom() creates a new mapping to access the ROM image, update all callers to remove this mapping after extracting the BIOS. Signed-off-by: Mikel Rychliski <mikel at mikelr.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_bios...

http://bugs.freedesktop.org/show_bug.cgi?id=14941 Summary: ioremap leak in DRM Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.or...

On Tue, Apr 21, 2020 at 7:45 PM Dejin Zheng <zhengdejin5 at gmail.com> wrote: > > It forgot to call bochs_hw_fini() to release related resources when > bochs_pci_probe() fail. eg: io virtual address get by ioremap(). Good start, although I think the best is to switch this driver to use pcim_*() functions and drop tons of legacy code. > Fixes: 81da8c3b8d3df6 ("drm/bochs: add drm_driver.release callback.") > CC: Andy Shevchenko <andy.shevchenko at gmail.com> > Signed-off-by: Dejin Zh...

...:24:24PM +0300, Andy Shevchenko wrote: > > On Tue, Apr 21, 2020 at 7:45 PM Dejin Zheng <zhengdejin5 at gmail.com> wrote: > > > > > > It forgot to call bochs_hw_fini() to release related resources when > > > bochs_pci_probe() fail. eg: io virtual address get by ioremap(). > > > > Good start, although I think the best is to switch this driver to use > > pcim_*() functions and drop tons of legacy code. > > > Andy, thanks for your encouragement, I think we might be able to fix this > issue first, after that, drop tons of legacy code by...

Hi, > I am a newbie, andy gave me some directions to submit the patch, eg: check > ioremap leak. At this time, I found that the bochs driver may have similar > problems, so I submitted this patch, then, Andy said the best is to switch > this driver to use pcim _ * () functions and drop tons of legacy code. > I think we might be able to fix this issue first, after that, drop tons...

I used ioremap() function to map the memory behind a PCI device to the processor main memory. How could xen be forced to use this mapped section for allocating memory for all DomU guests? Where in xen source code the respective modification has to be made? regards, Dinesh C ___________________________________...

I used ioremap() function to map the memory behind a PCI device to the processor main memory. How could xen be forced to use this mapped section for allocating memory for all DomU guests? Where in xen source code the respective modification has to be made? regards, Dinesh C ___________________________________...

Hi all, Does anybody have an idea about this "ioremap error" during the booting stage of VM CentOS7, although it can eventually bootup successfully. Regards, Allen 2014-11-05 Allen Qiu

...0x80/0x220 [radeon] drm_dev_register+0xa7/0x180 [drm] radeon_pci_probe+0x10f/0x1a0 [radeon] pci_device_probe+0xd4/0x140 Fix the issue by updating all drivers which can access a platform provided ROM. Instead of calling the helper function pci_platform_rom() which uses phys_to_virt(), call ioremap() directly on the pdev->rom. radeon_read_platform_bios() previously directly accessed an __iomem pointer. Avoid this by calling memcpy_fromio() instead of kmemdup(). pci_platform_rom() now has no remaining callers, so remove it. Link: https://lore.kernel.org/r/20200319021623.5426-1-mikel at m...

...0x80/0x220 [radeon] drm_dev_register+0xa7/0x180 [drm] radeon_pci_probe+0x10f/0x1a0 [radeon] pci_device_probe+0xd4/0x140 Fix the issue by updating all drivers which can access a platform provided ROM. Instead of calling the helper function pci_platform_rom() which uses phys_to_virt(), call ioremap() directly on the pdev->rom. radeon_read_platform_bios() previously directly accessed an __iomem pointer. Avoid this by calling memcpy_fromio() instead of kmemdup(). pci_platform_rom() now has no remaining callers, so remove it. Link: https://lore.kernel.org/r/20200319021623.5426-1-mikel at m...

...0x80/0x220 [radeon] drm_dev_register+0xa7/0x180 [drm] radeon_pci_probe+0x10f/0x1a0 [radeon] pci_device_probe+0xd4/0x140 Fix the issue by updating all drivers which can access a platform provided ROM. Instead of calling the helper function pci_platform_rom() which uses phys_to_virt(), call ioremap() directly on the pdev->rom. radeon_read_platform_bios() previously directly accessed an __iomem pointer. Avoid this by calling memcpy_fromio() instead of kmemdup(). pci_platform_rom() now has no remaining callers, so remove it. Link: https://lore.kernel.org/r/20200319021623.5426-1-mikel at m...

...0x80/0x220 [radeon] drm_dev_register+0xa7/0x180 [drm] radeon_pci_probe+0x10f/0x1a0 [radeon] pci_device_probe+0xd4/0x140 Fix the issue by updating all drivers which can access a platform provided ROM. Instead of calling the helper function pci_platform_rom() which uses phys_to_virt(), call ioremap() directly on the pdev->rom. radeon_read_platform_bios() previously directly accessed an __iomem pointer. Avoid this by calling memcpy_fromio() instead of kmemdup(). pci_platform_rom() now has no remaining callers, so remove it. Link: https://lore.kernel.org/r/20200319021623.5426-1-mikel at m...