* [PATCH] m68k: mm: Remove check for VM_IO to fix deferred I/O
@ 2022-01-28 17:30 Geert Uytterhoeven
2022-01-28 21:26 ` Michael Schmitz
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Geert Uytterhoeven @ 2022-01-28 17:30 UTC (permalink / raw)
To: linux-m68k
Cc: Andrew Morton, linux-mm, linux-fbdev, linux-kernel, Geert Uytterhoeven
When an application accesses a mapped frame buffer backed by deferred
I/O, it receives a segmentation fault. Fix this by removing the check
for VM_IO in do_page_fault().
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
This check was never present in a fault handler on any other
architecture than m68k.
Some digging revealed that it was added in v2.1.106, but I couldn't find
an email with a patch adding it. That same kernel version extended the
use of the hwreg_present() helper to HP9000/300, so the check might have
been needed there, perhaps only during development?
The Atari kernel relies heavily on hwreg_present() (both the success and
failure cases), and these still work, at least on ARAnyM.
---
arch/m68k/mm/fault.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/m68k/mm/fault.c b/arch/m68k/mm/fault.c
index 1493cf5eac1e7a39..71aa9f6315dc8028 100644
--- a/arch/m68k/mm/fault.c
+++ b/arch/m68k/mm/fault.c
@@ -93,8 +93,6 @@ int do_page_fault(struct pt_regs *regs, unsigned long address,
vma = find_vma(mm, address);
if (!vma)
goto map_err;
- if (vma->vm_flags & VM_IO)
- goto acc_err;
if (vma->vm_start <= address)
goto good_area;
if (!(vma->vm_flags & VM_GROWSDOWN))
--
2.25.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] m68k: mm: Remove check for VM_IO to fix deferred I/O
2022-01-28 17:30 [PATCH] m68k: mm: Remove check for VM_IO to fix deferred I/O Geert Uytterhoeven
@ 2022-01-28 21:26 ` Michael Schmitz
2022-01-28 23:55 ` Finn Thain
2022-01-30 0:32 ` Michael Schmitz
2022-01-31 2:21 ` Michael Schmitz
2 siblings, 1 reply; 8+ messages in thread
From: Michael Schmitz @ 2022-01-28 21:26 UTC (permalink / raw)
To: Geert Uytterhoeven, linux-m68k
Cc: Andrew Morton, linux-mm, linux-fbdev, linux-kernel, Finn Thain
Hi Geert,
for hwregs_present(), the exception fixup will handle any access error
(through send_fault_sig()), so this should continue to work.
Why the special handling of VM_IO pages? Maybe hp300 had marked all IO
register pages VM_IO to distinguish IO faults from VM faults...
The only other area I can imagine this might have an impact is the Mac's
pseudo-DMA - FInn might want to give this some testing.
Cheers,
Michael
Am 29.01.2022 um 06:30 schrieb Geert Uytterhoeven:
> When an application accesses a mapped frame buffer backed by deferred
> I/O, it receives a segmentation fault. Fix this by removing the check
> for VM_IO in do_page_fault().
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> This check was never present in a fault handler on any other
> architecture than m68k.
> Some digging revealed that it was added in v2.1.106, but I couldn't find
> an email with a patch adding it. That same kernel version extended the
> use of the hwreg_present() helper to HP9000/300, so the check might have
> been needed there, perhaps only during development?
> The Atari kernel relies heavily on hwreg_present() (both the success and
> failure cases), and these still work, at least on ARAnyM.
> ---
> arch/m68k/mm/fault.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/m68k/mm/fault.c b/arch/m68k/mm/fault.c
> index 1493cf5eac1e7a39..71aa9f6315dc8028 100644
> --- a/arch/m68k/mm/fault.c
> +++ b/arch/m68k/mm/fault.c
> @@ -93,8 +93,6 @@ int do_page_fault(struct pt_regs *regs, unsigned long address,
> vma = find_vma(mm, address);
> if (!vma)
> goto map_err;
> - if (vma->vm_flags & VM_IO)
> - goto acc_err;
> if (vma->vm_start <= address)
> goto good_area;
> if (!(vma->vm_flags & VM_GROWSDOWN))
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] m68k: mm: Remove check for VM_IO to fix deferred I/O
2022-01-28 21:26 ` Michael Schmitz
@ 2022-01-28 23:55 ` Finn Thain
2022-01-29 2:08 ` Michael Schmitz
0 siblings, 1 reply; 8+ messages in thread
From: Finn Thain @ 2022-01-28 23:55 UTC (permalink / raw)
To: Michael Schmitz
Cc: Geert Uytterhoeven, linux-m68k, Andrew Morton, linux-mm,
linux-fbdev, linux-kernel
On Sat, 29 Jan 2022, Michael Schmitz wrote:
> Hi Geert,
>
> for hwregs_present(), the exception fixup will handle any access error
> (through send_fault_sig()), so this should continue to work.
>
> Why the special handling of VM_IO pages? Maybe hp300 had marked all IO
> register pages VM_IO to distinguish IO faults from VM faults...
>
> The only other area I can imagine this might have an impact is the Mac's
> pseudo-DMA - FInn might want to give this some testing.
>
mac_scsi.c and mac_esp.c don't use ioremap(). They rely on head.S:
mmu_map_eq #0x50000000,#0x03000000,%d3
Having said that, I will run some tests if you still think it necessary.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] m68k: mm: Remove check for VM_IO to fix deferred I/O
2022-01-28 23:55 ` Finn Thain
@ 2022-01-29 2:08 ` Michael Schmitz
0 siblings, 0 replies; 8+ messages in thread
From: Michael Schmitz @ 2022-01-29 2:08 UTC (permalink / raw)
To: Finn Thain
Cc: Geert Uytterhoeven, linux-m68k, Andrew Morton, linux-mm,
linux-fbdev, linux-kernel
Hi Finn,
Am 29.01.2022 um 12:55 schrieb Finn Thain:
> On Sat, 29 Jan 2022, Michael Schmitz wrote:
>
>> Hi Geert,
>>
>> for hwregs_present(), the exception fixup will handle any access error
>> (through send_fault_sig()), so this should continue to work.
>>
>> Why the special handling of VM_IO pages? Maybe hp300 had marked all IO
>> register pages VM_IO to distinguish IO faults from VM faults...
>>
>> The only other area I can imagine this might have an impact is the Mac's
>> pseudo-DMA - FInn might want to give this some testing.
>>
>
> mac_scsi.c and mac_esp.c don't use ioremap(). They rely on head.S:
>
> mmu_map_eq #0x50000000,#0x03000000,%d3
>
> Having said that, I will run some tests if you still think it necessary.
No need for test then, thanks!
Cheers,
Michael
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] m68k: mm: Remove check for VM_IO to fix deferred I/O
2022-01-28 17:30 [PATCH] m68k: mm: Remove check for VM_IO to fix deferred I/O Geert Uytterhoeven
2022-01-28 21:26 ` Michael Schmitz
@ 2022-01-30 0:32 ` Michael Schmitz
2022-01-30 6:57 ` Michael Schmitz
2022-01-31 2:21 ` Michael Schmitz
2 siblings, 1 reply; 8+ messages in thread
From: Michael Schmitz @ 2022-01-30 0:32 UTC (permalink / raw)
To: Geert Uytterhoeven, linux-m68k
Cc: Andrew Morton, linux-mm, linux-fbdev, linux-kernel
Hi Geert,
testing this patch on my Falcon 030, I'm seeing a weird error checking
and mounting the root filesystem (pata-falcon). The system appears to
sit idle, never completing the journal recovery and mount. Still
investigating that.
Can't see how that would be caused by your patch, just saying I could
not yet test it.
Cheers,
Michael
Am 29.01.2022 um 06:30 schrieb Geert Uytterhoeven:
> When an application accesses a mapped frame buffer backed by deferred
> I/O, it receives a segmentation fault. Fix this by removing the check
> for VM_IO in do_page_fault().
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> This check was never present in a fault handler on any other
> architecture than m68k.
> Some digging revealed that it was added in v2.1.106, but I couldn't find
> an email with a patch adding it. That same kernel version extended the
> use of the hwreg_present() helper to HP9000/300, so the check might have
> been needed there, perhaps only during development?
> The Atari kernel relies heavily on hwreg_present() (both the success and
> failure cases), and these still work, at least on ARAnyM.
> ---
> arch/m68k/mm/fault.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/m68k/mm/fault.c b/arch/m68k/mm/fault.c
> index 1493cf5eac1e7a39..71aa9f6315dc8028 100644
> --- a/arch/m68k/mm/fault.c
> +++ b/arch/m68k/mm/fault.c
> @@ -93,8 +93,6 @@ int do_page_fault(struct pt_regs *regs, unsigned long address,
> vma = find_vma(mm, address);
> if (!vma)
> goto map_err;
> - if (vma->vm_flags & VM_IO)
> - goto acc_err;
> if (vma->vm_start <= address)
> goto good_area;
> if (!(vma->vm_flags & VM_GROWSDOWN))
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] m68k: mm: Remove check for VM_IO to fix deferred I/O
2022-01-30 0:32 ` Michael Schmitz
@ 2022-01-30 6:57 ` Michael Schmitz
0 siblings, 0 replies; 8+ messages in thread
From: Michael Schmitz @ 2022-01-30 6:57 UTC (permalink / raw)
To: Geert Uytterhoeven, linux-m68k
Cc: Andrew Morton, linux-mm, linux-fbdev, linux-kernel
Hi Geert,
Am 30.01.2022 um 13:32 schrieb Michael Schmitz:
> Hi Geert,
>
> testing this patch on my Falcon 030, I'm seeing a weird error checking
> and mounting the root filesystem (pata-falcon). The system appears to
> sit idle, never completing the journal recovery and mount. Still
> investigating that.
Belay that - not related to your patch, must be some other regression
since v5.16 that I'm seeing there.
Just ignore the noise ...
Cheers,
Michael
> Can't see how that would be caused by your patch, just saying I could
> not yet test it.
>
> Cheers,
>
> Michael
>
>
> Am 29.01.2022 um 06:30 schrieb Geert Uytterhoeven:
>> When an application accesses a mapped frame buffer backed by deferred
>> I/O, it receives a segmentation fault. Fix this by removing the check
>> for VM_IO in do_page_fault().
>>
>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>> ---
>> This check was never present in a fault handler on any other
>> architecture than m68k.
>> Some digging revealed that it was added in v2.1.106, but I couldn't find
>> an email with a patch adding it. That same kernel version extended the
>> use of the hwreg_present() helper to HP9000/300, so the check might have
>> been needed there, perhaps only during development?
>> The Atari kernel relies heavily on hwreg_present() (both the success and
>> failure cases), and these still work, at least on ARAnyM.
>> ---
>> arch/m68k/mm/fault.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/arch/m68k/mm/fault.c b/arch/m68k/mm/fault.c
>> index 1493cf5eac1e7a39..71aa9f6315dc8028 100644
>> --- a/arch/m68k/mm/fault.c
>> +++ b/arch/m68k/mm/fault.c
>> @@ -93,8 +93,6 @@ int do_page_fault(struct pt_regs *regs, unsigned
>> long address,
>> vma = find_vma(mm, address);
>> if (!vma)
>> goto map_err;
>> - if (vma->vm_flags & VM_IO)
>> - goto acc_err;
>> if (vma->vm_start <= address)
>> goto good_area;
>> if (!(vma->vm_flags & VM_GROWSDOWN))
>>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] m68k: mm: Remove check for VM_IO to fix deferred I/O
2022-01-28 17:30 [PATCH] m68k: mm: Remove check for VM_IO to fix deferred I/O Geert Uytterhoeven
2022-01-28 21:26 ` Michael Schmitz
2022-01-30 0:32 ` Michael Schmitz
@ 2022-01-31 2:21 ` Michael Schmitz
2022-02-07 13:06 ` Geert Uytterhoeven
2 siblings, 1 reply; 8+ messages in thread
From: Michael Schmitz @ 2022-01-31 2:21 UTC (permalink / raw)
To: Geert Uytterhoeven, linux-m68k
Cc: Andrew Morton, linux-mm, linux-fbdev, linux-kernel
Hi Geert,
Am 29.01.2022 um 06:30 schrieb Geert Uytterhoeven:
> When an application accesses a mapped frame buffer backed by deferred
> I/O, it receives a segmentation fault. Fix this by removing the check
> for VM_IO in do_page_fault().
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Works fine on my Falcon030 when applied to v5.16.
Tested-by: Michael Schmitz <schmitzmic@gmail.com>
> ---
> This check was never present in a fault handler on any other
> architecture than m68k.
> Some digging revealed that it was added in v2.1.106, but I couldn't find
> an email with a patch adding it. That same kernel version extended the
> use of the hwreg_present() helper to HP9000/300, so the check might have
> been needed there, perhaps only during development?
> The Atari kernel relies heavily on hwreg_present() (both the success and
> failure cases), and these still work, at least on ARAnyM.
> ---
> arch/m68k/mm/fault.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/m68k/mm/fault.c b/arch/m68k/mm/fault.c
> index 1493cf5eac1e7a39..71aa9f6315dc8028 100644
> --- a/arch/m68k/mm/fault.c
> +++ b/arch/m68k/mm/fault.c
> @@ -93,8 +93,6 @@ int do_page_fault(struct pt_regs *regs, unsigned long address,
> vma = find_vma(mm, address);
> if (!vma)
> goto map_err;
> - if (vma->vm_flags & VM_IO)
> - goto acc_err;
> if (vma->vm_start <= address)
> goto good_area;
> if (!(vma->vm_flags & VM_GROWSDOWN))
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] m68k: mm: Remove check for VM_IO to fix deferred I/O
2022-01-31 2:21 ` Michael Schmitz
@ 2022-02-07 13:06 ` Geert Uytterhoeven
0 siblings, 0 replies; 8+ messages in thread
From: Geert Uytterhoeven @ 2022-02-07 13:06 UTC (permalink / raw)
To: Michael Schmitz
Cc: linux-m68k, Andrew Morton, Linux MM,
Linux Fbdev development list, Linux Kernel Mailing List
On Mon, Jan 31, 2022 at 3:22 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
> Am 29.01.2022 um 06:30 schrieb Geert Uytterhoeven:
> > When an application accesses a mapped frame buffer backed by deferred
> > I/O, it receives a segmentation fault. Fix this by removing the check
> > for VM_IO in do_page_fault().
> >
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Works fine on my Falcon030 when applied to v5.16.
>
> Tested-by: Michael Schmitz <schmitzmic@gmail.com>
Thanks, queued in the m68k for-v5.18 branch.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-02-07 13:06 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-28 17:30 [PATCH] m68k: mm: Remove check for VM_IO to fix deferred I/O Geert Uytterhoeven
2022-01-28 21:26 ` Michael Schmitz
2022-01-28 23:55 ` Finn Thain
2022-01-29 2:08 ` Michael Schmitz
2022-01-30 0:32 ` Michael Schmitz
2022-01-30 6:57 ` Michael Schmitz
2022-01-31 2:21 ` Michael Schmitz
2022-02-07 13:06 ` Geert Uytterhoeven
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).