Re: stack smashing detected

[Michael Schmitz <schmitzmic@gmail.com>]

Hi Stan,

Am 10.02.2023 um 13:24 schrieb Stan Johnson:
> Hi Michael,
>
> On 2/8/23 8:41 PM, Michael Schmitz wrote:
> > ...
> >
> > Following the 040 code a bit further, I suspect that happens in the 040
> > writeback handler, so this may be a red herring.
> >
> > > I'll try and log such accesses caught by exception tables on 030 to see
> > > if they are rare enough to allow adding a kernel log message...
> >
> > Looks like this kind of event is rare enough to not trigger in a normal
> > boot on my 030.
>
> Have you seen the error using my modified config file? Perhaps I'm not
> including something that's causing (or revealing) the problem.

I haven't seen these stack smashing errors ever, but that's with a 
really ancient user space and a kernel config for Atari that only 
includes the bare minimum.

> > Please give the attached patch a try so we can confirm
> > (or rule out) that user space access faults from kernel mode are to
> > blame for your stack smashes.
> > ...
>
> With "0001-m68k-debug-exception-handling-data-faults-on-030.patch",
>
> Kernel                 Stack-Smashing
> 6.2.0-rc7 (no patch)      4, 3, 3     (from earlier test)
> 6.2.0-rc7 (new patch)     6, 2, 0
>
> The earlier patch is not applied. Serial console log is attached.

Without Al's patch, I doubt even in case a uaccess fault happens with 
signal pending we'd return -1 from send_fault_sig() (the no_context path 
isn't taken and do_page_fault() returns without error). No kernel 
messages expected in that case. But none seen otherwise either which 
indicates exception handling in uaccess isn't a problem.

Not sure it's worth the hassle to retry with both patches applied...

Thanks,

	Michael


> thanks
>
> -Stan