Linux M68K Architecture development
 help / color / mirror / Atom feed
From: Greg Ungerer <gerg@linux-m68k.org>
To: Finn Thain <fthain@linux-m68k.org>
Cc: Michael Schmitz <schmitzmic@gmail.com>,
	linux-m68k@vger.kernel.org, geert@linux-m68k.org,
	linux-m68k@lists.linux-m68k.org
Subject: Re: [PATCH v4 1/2] m68k: Handle __generic_copy_to_user faults more carefully
Date: Fri, 9 Aug 2024 00:52:06 +1000	[thread overview]
Message-ID: <00ccfc03-9032-435b-8082-905e225c7a0f@linux-m68k.org> (raw)
In-Reply-To: <727be0d7-a3ed-d3eb-2a13-c6ac316cd25d@linux-m68k.org>

Hi Finn,

On 8/8/24 16:56, Finn Thain wrote:
> On Thu, 8 Aug 2024, Greg Ungerer wrote:
>> On 8/8/24 11:57, Finn Thain wrote:
>>>> I'm afraid I've lost track of where we're at with this patch series.
>>>> Does it need more work, or more bug reports such as the one below?
>>>
>>> Apparently the series is waiting for some testing on a Coldfire system
>>> with MMU.
>>
>> Ok, I am in a state that I can do that now (I managed to fix my M5475EVB
>> board).
> 
> Thanks, Greg.
> 
>> If I test the v4 versions of this patch set that should do the job?
>>
> 
> There are 3 patches that need some more testing, one from me and two from
> Michael:
> 
> [PATCH] m68k: Handle put_user() faults more carefully
> [PATCH v4 1/2] m68k: Handle __generic_copy_to_user faults more carefully
> [PATCH v4 2/2] m68k: improve __constant_copy_to_user_asm() fault handling
> 
> They were posted in two threads:
> 
> https://lore.kernel.org/linux-m68k/1ed9c4c753395510c1a8df9c35e2ad4c31c90f95.1714265926.git.fthain@linux-m68k.org/T/
> https://lore.kernel.org/linux-m68k/CAMuHMdVrOnOQwCxk42YCjEkbfL-YDSvpf_xTaouv9hUs2bO+qg@mail.gmail.com/T/
> 
> On 680x0, one of the bugs was brought to light with 'stress-ng
> --sysbadaddr -1'. The others required special test programs.
> 
> I've no idea whether Coldfire silicon is susceptable at all, and if it is,
> whether the same reproducers would work. But that's neither here nor there
> from a regression testing standpoint.

Ok, thanks for the links. I have applied and tested those, no obvious regressions.
So for all of these patches:

Tested-by: Greg Ungerer <gerg@linux-m68k.org>

I tried out the "stress-ng --sysbadaddr -1" test, and that didn't go so well for me:

# stress-ng --sysbadaddr -1
stress-ng: info:  [37] defaulting to a 86400 second (1 day, 0.00 secs) run per stressor
stress-ng: info:  [37] dispatching hogs: 1 sysbadaddr
*** ILLEGAL INSTRUCTION ***   FORMAT=4
Current process id is 39
BAD KERNEL TRAP: 00000000
Modules linked in:
PC: [<00000000>] 0x0
SR: 2004  SP: 6504e563  a2: 008ee380
d0: 000000f7    d1: 00000000    d2: 00000000    d3: 00000000
d4: 00a87b80    d5: bfbf3814    a0: 00000000    a1: bfbf3814
Process stress-ng-sysba (pid: 39, task=4dbb2ec5)
Frame format=4 eff addr=480a2004 pc=0002b154
Stack from 00adff20:
         00ade000 00000000 00000000 000000f7 00000000 00000004 00a87b80 00000000
         00000000 00000000 00000000 008ee380 0002ab5c 00000100 00000122 fffffff6
         bfbf376c 0002b29e 000000f7 bfbf3814 00000000 00000000 00ade000 0002b222
         00ae0800 80118988 00000000 00000005 bfbf37a0 00000005 bfbf3814 00adffcc
         00023d2c 00adffcc 00000000 00000000 00000000 00000000 000000f7 00000000
         80118b46 00021850 00024b00 000000f7 bfbf3814 00000000 00000000 bfbf3814
Call Trace: [<0002ab5c>] child_wait_callback+0x0/0x24
  [<0002b29e>] sys_wait4+0x7c/0x8e
  [<0002b222>] sys_wait4+0x0/0x8e
  [<00023d2c>] buserr_c+0xb0/0x152
  [<00021850>] buserr+0x28/0x30
  [<00024b00>] system_call+0x54/0xa8

But that is the same with and without these patches.

Regards
Greg


  reply	other threads:[~2024-08-08 14:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-29  3:09 [PATCH v4 0/2] m68k uaccess fault handling fixes Michael Schmitz
2024-04-29  3:09 ` [PATCH v4 1/2] m68k: Handle __generic_copy_to_user faults more carefully Michael Schmitz
2024-08-07  8:14   ` Finn Thain
2024-08-07 19:32     ` Michael Schmitz
2024-08-08  1:57       ` Finn Thain
2024-08-08  6:05         ` Greg Ungerer
2024-08-08  6:56           ` Finn Thain
2024-08-08 14:52             ` Greg Ungerer [this message]
2024-08-08 19:27               ` Michael Schmitz
2024-08-09  3:34                 ` Finn Thain
2024-08-09  8:03                   ` Michael Schmitz
2024-08-09 12:58                     ` Greg Ungerer
2024-08-09  3:22               ` Finn Thain
2024-08-08  6:58           ` Michael Schmitz
2024-04-29  3:09 ` [PATCH v4 2/2] m68k: improve __constant_copy_to_user_asm() fault handling Michael Schmitz
2024-04-29  7:58 ` [PATCH v4 0/2] m68k uaccess fault handling fixes Greg Ungerer
2024-04-29  8:08   ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=00ccfc03-9032-435b-8082-905e225c7a0f@linux-m68k.org \
    --to=gerg@linux-m68k.org \
    --cc=fthain@linux-m68k.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=schmitzmic@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox