[PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table

[PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table

[Michael Schmitz]

__get_kernel_nofault() does copy data in supervisor mode when
forcing a task backtrace dump through the sysrq trigger.

Our 030 bus error handler is ill equipped to deal with this:

Whenever ssw indicates a kernel mode access on a data fault,
we don't even attempt to handle the fault and instead send
a bus error signal (or panic). As a result, the check for
exception handling at the fault PC (buried in send_sig_fault()
which gets called from do_page_fault() eventually) is never
used.

Both 040 and 060 access error handlers do not care whether
a fault happened on supervisor mode access, and will call
do_page_fault() even on those.

Add a check in bus_error030 to call do_page_fault() in case
we do have an entry for the fault PC in our exception table.

Tested on 030 Atari Falcon.

Signed-off-by: Michael Schmitz <schmitzmic@gmail.com># Please enter the commit message for your changes. Lines starting
CC: Eero Tamminen <oak@helsinkinet.fi>
CC: Finn Thain <ftain@linux-m68k.org>
CC: Andreas Schwab <schwab@linux-m68k.org>
CC: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/daca2f68-19fa-a2b6-97c6-16b5b7e26afe@helsinkinet.fi
---
 arch/m68k/kernel/traps.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/m68k/kernel/traps.c b/arch/m68k/kernel/traps.c
index 5c8cba0efc63..67576fb0c466 100644
--- a/arch/m68k/kernel/traps.c
+++ b/arch/m68k/kernel/traps.c
@@ -30,6 +30,7 @@
 #include <linux/init.h>
 #include <linux/ptrace.h>
 #include <linux/kallsyms.h>
+#include <linux/extable.h>
 
 #include <asm/setup.h>
 #include <asm/fpu.h>
@@ -545,7 +546,7 @@ static inline void bus_error030 (struct frame *fp)
 			errorcode |= 2;
 
 		if (mmusr & (MMU_I | MMU_WP)) {
-			if (ssw & 4) {
+			if (ssw & 4 && !search_exception_tables(fp->ptregs.pc)) {
 				pr_err("Data %s fault at %#010lx in %s (pc=%#lx)\n",
 				       ssw & RW ? "read" : "write",
 				       fp->un.fmtb.daddr,
-- 
2.17.1

Re: [PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table

[Eero Tamminen]

Hi Michael,

On 22.2.2023 21.50, Michael Schmitz wrote:
> __get_kernel_nofault() does copy data in supervisor mode when
> forcing a task backtrace dump through the sysrq trigger.
> 
> Our 030 bus error handler is ill equipped to deal with this:
> 
> Whenever ssw indicates a kernel mode access on a data fault,
> we don't even attempt to handle the fault and instead send
> a bus error signal (or panic). As a result, the check for
> exception handling at the fault PC (buried in send_sig_fault()
> which gets called from do_page_fault() eventually) is never
> used.
> 
> Both 040 and 060 access error handlers do not care whether
> a fault happened on supervisor mode access, and will call
> do_page_fault() even on those.
> 
> Add a check in bus_error030 to call do_page_fault() in case
> we do have an entry for the fault PC in our exception table.
> 
> Tested on 030 Atari Falcon.


I've verified that the kernel Oops was there with unpatched kernel, and 
this fixes it, also when using Hatari emulator 030 / Atari Falcon emulation.

(Verified both with both v6.0 & v6.2 of Linus' kernel sources.)


	- Eero


> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com># Please enter the commit message for your changes. Lines starting
> CC: Eero Tamminen <oak@helsinkinet.fi>
> CC: Finn Thain <ftain@linux-m68k.org>
> CC: Andreas Schwab <schwab@linux-m68k.org>
> CC: Geert Uytterhoeven <geert@linux-m68k.org>
> Link: https://lore.kernel.org/r/daca2f68-19fa-a2b6-97c6-16b5b7e26afe@helsinkinet.fi
> ---
>   arch/m68k/kernel/traps.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/m68k/kernel/traps.c b/arch/m68k/kernel/traps.c
> index 5c8cba0efc63..67576fb0c466 100644
> --- a/arch/m68k/kernel/traps.c
> +++ b/arch/m68k/kernel/traps.c
> @@ -30,6 +30,7 @@
>   #include <linux/init.h>
>   #include <linux/ptrace.h>
>   #include <linux/kallsyms.h>
> +#include <linux/extable.h>
>   
>   #include <asm/setup.h>
>   #include <asm/fpu.h>
> @@ -545,7 +546,7 @@ static inline void bus_error030 (struct frame *fp)
>   			errorcode |= 2;
>   
>   		if (mmusr & (MMU_I | MMU_WP)) {
> -			if (ssw & 4) {
> +			if (ssw & 4 && !search_exception_tables(fp->ptregs.pc)) {
>   				pr_err("Data %s fault at %#010lx in %s (pc=%#lx)\n",
>   				       ssw & RW ? "read" : "write",
>   				       fp->un.fmtb.daddr,

Re: [PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table

[Michael Schmitz]

Thanks Eero,

I'll add your Tested-by (and Reported-by; sorry to have forgotten that) 
in v2.

Cheers,

	Michael


Am 24.02.2023 um 13:31 schrieb Eero Tamminen:
> Hi Michael,
>
> On 22.2.2023 21.50, Michael Schmitz wrote:
>> __get_kernel_nofault() does copy data in supervisor mode when
>> forcing a task backtrace dump through the sysrq trigger.
>>
>> Our 030 bus error handler is ill equipped to deal with this:
>>
>> Whenever ssw indicates a kernel mode access on a data fault,
>> we don't even attempt to handle the fault and instead send
>> a bus error signal (or panic). As a result, the check for
>> exception handling at the fault PC (buried in send_sig_fault()
>> which gets called from do_page_fault() eventually) is never
>> used.
>>
>> Both 040 and 060 access error handlers do not care whether
>> a fault happened on supervisor mode access, and will call
>> do_page_fault() even on those.
>>
>> Add a check in bus_error030 to call do_page_fault() in case
>> we do have an entry for the fault PC in our exception table.
>>
>> Tested on 030 Atari Falcon.
>
>
> I've verified that the kernel Oops was there with unpatched kernel, and
> this fixes it, also when using Hatari emulator 030 / Atari Falcon
> emulation.
>
> (Verified both with both v6.0 & v6.2 of Linus' kernel sources.)
>
>
>     - Eero
>
>
>> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com># Please enter
>> the commit message for your changes. Lines starting
>> CC: Eero Tamminen <oak@helsinkinet.fi>
>> CC: Finn Thain <ftain@linux-m68k.org>
>> CC: Andreas Schwab <schwab@linux-m68k.org>
>> CC: Geert Uytterhoeven <geert@linux-m68k.org>
>> Link:
>> https://lore.kernel.org/r/daca2f68-19fa-a2b6-97c6-16b5b7e26afe@helsinkinet.fi
>>
>> ---
>>   arch/m68k/kernel/traps.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/m68k/kernel/traps.c b/arch/m68k/kernel/traps.c
>> index 5c8cba0efc63..67576fb0c466 100644
>> --- a/arch/m68k/kernel/traps.c
>> +++ b/arch/m68k/kernel/traps.c
>> @@ -30,6 +30,7 @@
>>   #include <linux/init.h>
>>   #include <linux/ptrace.h>
>>   #include <linux/kallsyms.h>
>> +#include <linux/extable.h>
>>     #include <asm/setup.h>
>>   #include <asm/fpu.h>
>> @@ -545,7 +546,7 @@ static inline void bus_error030 (struct frame *fp)
>>               errorcode |= 2;
>>             if (mmusr & (MMU_I | MMU_WP)) {
>> -            if (ssw & 4) {
>> +            if (ssw & 4 && !search_exception_tables(fp->ptregs.pc)) {
>>                   pr_err("Data %s fault at %#010lx in %s (pc=%#lx)\n",
>>                          ssw & RW ? "read" : "write",
>>                          fp->un.fmtb.daddr,

Re: [PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table

[Geert Uytterhoeven]

Hi Michael,

On Wed, Feb 22, 2023 at 8:52 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> __get_kernel_nofault() does copy data in supervisor mode when
> forcing a task backtrace dump through the sysrq trigger.
>
> Our 030 bus error handler is ill equipped to deal with this:
>
> Whenever ssw indicates a kernel mode access on a data fault,
> we don't even attempt to handle the fault and instead send
> a bus error signal (or panic). As a result, the check for
> exception handling at the fault PC (buried in send_sig_fault()
> which gets called from do_page_fault() eventually) is never
> used.
>
> Both 040 and 060 access error handlers do not care whether
> a fault happened on supervisor mode access, and will call
> do_page_fault() even on those.
>
> Add a check in bus_error030 to call do_page_fault() in case
> we do have an entry for the fault PC in our exception table.
>
> Tested on 030 Atari Falcon.

Thanks for your patch!

> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com># Please enter the commit message for your changes. Lines starting

Please remove the comment ;-)

> CC: Eero Tamminen <oak@helsinkinet.fi>
> CC: Finn Thain <ftain@linux-m68k.org>
> CC: Andreas Schwab <schwab@linux-m68k.org>
> CC: Geert Uytterhoeven <geert@linux-m68k.org>
> Link: https://lore.kernel.org/r/daca2f68-19fa-a2b6-97c6-16b5b7e26afe@helsinkinet.fi

404

I assume that a message from debian-68k?
Do you have a https://lists.debian.org/debian-68k/ link?

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

Re: [PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table

[Michael Schmitz]

Hi Geert,

thanks for your feedback!

On 28/02/23 09:19, Geert Uytterhoeven wrote:
> Hi Michael,
>
> On Wed, Feb 22, 2023 at 8:52 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> __get_kernel_nofault() does copy data in supervisor mode when
>> forcing a task backtrace dump through the sysrq trigger.
>>
>> Our 030 bus error handler is ill equipped to deal with this:
>>
>> Whenever ssw indicates a kernel mode access on a data fault,
>> we don't even attempt to handle the fault and instead send
>> a bus error signal (or panic). As a result, the check for
>> exception handling at the fault PC (buried in send_sig_fault()
>> which gets called from do_page_fault() eventually) is never
>> used.
>>
>> Both 040 and 060 access error handlers do not care whether
>> a fault happened on supervisor mode access, and will call
>> do_page_fault() even on those.
>>
>> Add a check in bus_error030 to call do_page_fault() in case
>> we do have an entry for the fault PC in our exception table.
>>
>> Tested on 030 Atari Falcon.
> Thanks for your patch!
>
>> Signed-off-by: Michael Schmitz <schmitzmic@gmail.com># Please enter the commit message for your changes. Lines starting
> Please remove the comment ;-)

Done that already for v2.

>
>> CC: Eero Tamminen <oak@helsinkinet.fi>
>> CC: Finn Thain <ftain@linux-m68k.org>
>> CC: Andreas Schwab <schwab@linux-m68k.org>
>> CC: Geert Uytterhoeven <geert@linux-m68k.org>
>> Link: https://lore.kernel.org/r/daca2f68-19fa-a2b6-97c6-16b5b7e26afe@helsinkinet.fi
> 404
>
> I assume that a message from debian-68k?

No, oddly enough that is a message that I have received with CC to 
linux-m68k (but not from vger!). And mail-archive.com has it:

https://www.mail-archive.com/linux-m68k@vger.kernel.org/msg13081.html

And also on marc.info:

https://marc.info/?l=linux-m68k&m=155477039405576&w=2

Later one with an experimental patch of mine:

https://marc.info/?l=linux-m68k&m=155494864731013&w=2

None of these messages show up on a search of lore...

What source do you prefer - marc.info or mail-archive.com?

Cheers,

     Michael


> Do you have a https://lists.debian.org/debian-68k/ link?
>
> Gr{oetje,eeting}s,
>
>                          Geert
>

Re: [PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table

[Geert Uytterhoeven]

Hi Michael,

On Tue, Feb 28, 2023 at 12:28 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
> On 28/02/23 09:19, Geert Uytterhoeven wrote:
> > On Wed, Feb 22, 2023 at 8:52 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
> >> Link: https://lore.kernel.org/r/daca2f68-19fa-a2b6-97c6-16b5b7e26afe@helsinkinet.fi
> > 404
> >
> > I assume that a message from debian-68k?
>
> No, oddly enough that is a message that I have received with CC to
> linux-m68k (but not from vger!). And mail-archive.com has it:
>
> https://www.mail-archive.com/linux-m68k@vger.kernel.org/msg13081.html
>
> And also on marc.info:
>
> https://marc.info/?l=linux-m68k&m=155477039405576&w=2

That one has a different Message-ID:
alpine.LNX.2.21.1904141327340.130@nippy.intranet

> Later one with an experimental patch of mine:
>
> https://marc.info/?l=linux-m68k&m=155494864731013&w=2
>
> None of these messages show up on a search of lore...

Indeed, and I did receive them through vger.

> What source do you prefer - marc.info or mail-archive.com?

Let's keep the lore link with the actual Message-ID.
Missing emails on lore can be backfilled later...

Upon closer look, this predates lore collecting emails, so perhaps
something went wrong while importing my old archives I sent
to kernel.org. To be investigated...


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

Re: [PATCH RFC v1] m68k: kernel/traps.c - only force 030 bus error if PC not in exception table

[Michael Schmitz]

Hi Geert,

On 28/02/23 21:08, Geert Uytterhoeven wrote:
> Hi Michael,
>
> On Tue, Feb 28, 2023 at 12:28 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
>> On 28/02/23 09:19, Geert Uytterhoeven wrote:
>>> On Wed, Feb 22, 2023 at 8:52 PM Michael Schmitz <schmitzmic@gmail.com> wrote:
>>>> Link: https://lore.kernel.org/r/daca2f68-19fa-a2b6-97c6-16b5b7e26afe@helsinkinet.fi
>>> 404
>>>
>>> I assume that a message from debian-68k?
>> No, oddly enough that is a message that I have received with CC to
>> linux-m68k (but not from vger!). And mail-archive.com has it:
>>
>> https://www.mail-archive.com/linux-m68k@vger.kernel.org/msg13081.html
>>
>> And also on marc.info:
>>
>> https://marc.info/?l=linux-m68k&m=155477039405576&w=2
> That one has a different Message-ID:
> alpine.LNX.2.21.1904141327340.130@nippy.intranet
I get alpine.LNX.2.21.1904091023540.25@nippy.intranet ...
>
>> Later one with an experimental patch of mine:
>>
>> https://marc.info/?l=linux-m68k&m=155494864731013&w=2

63130691-1984-c423-c1f2-73bfd8d3dcd3@gmail.com

>>
>> None of these messages show up on a search of lore...
> Indeed, and I did receive them through vger.
>
>> What source do you prefer - marc.info or mail-archive.com?
> Let's keep the lore link with the actual Message-ID.
> Missing emails on lore can be backfilled later...
>
> Upon closer look, this predates lore collecting emails, so perhaps
> something went wrong while importing my old archives I sent
> to kernel.org. To be investigated...

OK - I'll send around v2 with lore links and comment removed later.

Cheers,

     Michael

>
>
> 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