search for: entry_sysenter_32

...: Re-implement SYSENTER using the new C path"), the stack > frame that is passed to xen_sysexit is no longer a "standard" one (i.e. > it's not pt_regs). > > Since we end up calling xen_iret from xen_sysexit we don't need to fix > up the stack and instead follow entry_SYSENTER_32's IRET path directly > to xen_iret. > > We can do the same thing for compat mode even though stack does not need > to be fixed. This will allow us to drop usergs_sysret32 paravirt op (in > the subsequent patch) Looks generally quite nice. Minor comments below: > --- a/arch/...

...: Re-implement SYSENTER using the new C path"), the stack > frame that is passed to xen_sysexit is no longer a "standard" one (i.e. > it's not pt_regs). > > Since we end up calling xen_iret from xen_sysexit we don't need to fix > up the stack and instead follow entry_SYSENTER_32's IRET path directly > to xen_iret. > > We can do the same thing for compat mode even though stack does not need > to be fixed. This will allow us to drop usergs_sysret32 paravirt op (in > the subsequent patch) Looks generally quite nice. Minor comments below: > --- a/arch/...

...864] ? __vunmap+0x89/0xef [ 7.407960] ? do_init_module+0x1a/0x23f [ 7.408055] do_init_module+0x82/0x23f [ 7.408153] load_module+0x243c/0x36ae [ 7.408253] ? kernel_read+0x4c/0xa1 [ 7.408350] SyS_finit_module+0x78/0x8d [ 7.408447] do_fast_syscall_32+0xc1/0x31b [ 7.408545] entry_SYSENTER_32+0x4e/0x7c [ 7.408640] EIP: 0xb7ee9ad5 [ 7.408730] EFLAGS: 00000296 CPU: 0 [ 7.408823] EAX: ffffffda EBX: 00000019 ECX: b7ce0bdd EDX: 00000000 [ 7.408920] ESI: 00eb6670 EDI: 00ebe610 EBP: 00000000 ESP: bff8704c [ 7.409017] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b [ 7.409113] =...

...path"), the stack >>> frame that is passed to xen_sysexit is no longer a "standard" one (i.e. >>> it's not pt_regs). >>> >>> Since we end up calling xen_iret from xen_sysexit we don't need to fix >>> up the stack and instead follow entry_SYSENTER_32's IRET path directly >>> to xen_iret. >>> >>> We can do the same thing for compat mode even though stack does not need >>> to be fixed. This will allow us to drop usergs_sysret32 paravirt op (in >>> the subsequent patch) >> >> Looks gener...

...: Re-implement SYSENTER using the new C path"), the stack > frame that is passed to xen_sysexit is no longer a "standard" one (i.e. > it's not pt_regs). > > Since we end up calling xen_iret from xen_sysexit we don't need to fix > up the stack and instead follow entry_SYSENTER_32's IRET path directly > to xen_iret. > > We can do the same thing for compat mode even though stack does not need > to be fixed. This will allow us to drop usergs_sysret32 paravirt op (in > the subsequent patch) > > Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracl...

...: Re-implement SYSENTER using the new C path"), the stack > frame that is passed to xen_sysexit is no longer a "standard" one (i.e. > it's not pt_regs). > > Since we end up calling xen_iret from xen_sysexit we don't need to fix > up the stack and instead follow entry_SYSENTER_32's IRET path directly > to xen_iret. > > We can do the same thing for compat mode even though stack does not need > to be fixed. This will allow us to drop usergs_sysret32 paravirt op (in > the subsequent patch) > > Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracl...

...TER using the new C path"), the stack >> frame that is passed to xen_sysexit is no longer a "standard" one (i.e. >> it's not pt_regs). >> >> Since we end up calling xen_iret from xen_sysexit we don't need to fix >> up the stack and instead follow entry_SYSENTER_32's IRET path directly >> to xen_iret. >> >> We can do the same thing for compat mode even though stack does not need >> to be fixed. This will allow us to drop usergs_sysret32 paravirt op (in >> the subsequent patch) > > Looks generally quite nice. Minor comm...

...13c > ? nvif_client_ioctl+0x2b/0x40 [nouveau] > ? usif_ioctl+0x4eb/0x790 [nouveau] > ? nouveau_drm_ioctl+0xab/0xb0 [nouveau] > ? nouveau_pmops_resume+0x80/0x80 [nouveau] > ? do_vfs_ioctl+0x91/0x6b0 > ? SyS_ioctl+0x60/0x70 > ? do_fast_syscall_32+0x8a/0x150 > ? entry_SYSENTER_32+0x4e/0x7c > ---[ end trace 1bf6c731018c2e52 ]--- > > followed by > nouveau 0000:03:00.0: fifo: channel 6 [mpv/vo[3535]] kick timeout > nouveau: mpv/vo[3535]:00000000:0000906f: detach gr failed, -110 Are you using mpv in conjunction with the GL video output and VDPAU-based accelerat...

...9b4c ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack frame that is passed to xen_sysexit is no longer a "standard" one (i.e. it's not pt_regs). Since we end up calling xen_iret from xen_sysexit we don't need to fix up the stack and instead follow entry_SYSENTER_32's IRET path directly to xen_iret. We can do the same thing for compat mode even though stack does not need to be fixed. This will allow us to drop usergs_sysret32 paravirt op (in the subsequent patch) Signed-off-by: Boris Ostrovsky <boris.ostrovsky at oracle.com> Suggested-by: Andy Luto...

...9e/0x13c ? __check_object_size+0x9e/0x13c ? nvif_client_ioctl+0x2b/0x40 [nouveau] ? usif_ioctl+0x4eb/0x790 [nouveau] ? nouveau_drm_ioctl+0xab/0xb0 [nouveau] ? nouveau_pmops_resume+0x80/0x80 [nouveau] ? do_vfs_ioctl+0x91/0x6b0 ? SyS_ioctl+0x60/0x70 ? do_fast_syscall_32+0x8a/0x150 ? entry_SYSENTER_32+0x4e/0x7c ---[ end trace 1bf6c731018c2e52 ]--- followed by nouveau 0000:03:00.0: fifo: channel 6 [mpv/vo[3535]] kick timeout nouveau: mpv/vo[3535]:00000000:0000906f: detach gr failed, -110 Then there are nouveau 0000:03:00.0: mpv/vo[3535]: failed to idle channel 6 [mpv/vo[3535]] Is this a known...

...deon] do_one_initcall+0x42/0x200 ? kvfree+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 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....

...deon] do_one_initcall+0x42/0x200 ? kvfree+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> -...

..._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 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_pl...

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 +

...243.143861] ? _raw_spin_unlock+0x10/0x23 [ 243.143861] ? handle_mm_fault+0x67d/0x859 [ 243.143861] ? __fget+0x5c/0x93 [ 243.143861] ? __fget_light+0x43/0x4d [ 243.143861] ksys_ioctl+0x33/0x52 [ 243.143861] sys_ioctl+0x11/0x13 [ 243.143861] do_fast_syscall_32+0x8f/0x1c2 [ 243.143861] entry_SYSENTER_32+0x6b/0xbe [ 243.143861] EIP: 0xb7fb9af5 [ 243.143861] Code: 82 f8 ff ff 8b 55 08 8b 80 5c cd ff ff 85 d2 74 02 89 02 5d c3 8b 04 24 c3 8b 0c 24 c3 8b 1c 24 c3 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76 [ 243.143861] EAX: ffffffda EBX: 000...

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. (I ended up patching TEST with XOR to avoid extra NOPs, even though I said yesterday it would be wrong. It's not wrong) As result of this patch irq_enable_sysexit and

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. (I ended up patching TEST with XOR to avoid extra NOPs, even though I said yesterday it would be wrong. It's not wrong) As result of this patch irq_enable_sysexit and

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

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not used anymore by anyone and so can be removed. v2: * patch both TEST and JZ intructions with a

The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit (and sysret32 in compat mode) pv ops, as suggested by Andy. As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not used anymore by anyone and so can be removed. v2: * patch both TEST and JZ intructions with a