Re: [PATCH v4 2/5] sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC III

[John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>]

Hi Anthony,

On Mon, 2025-09-08 at 15:47 -0700, Anthony Yznaga wrote:
> > Could it be that we need to enable the code guarded by DCACHE_ALIASING_POSSIBLE
> > unconditionally?
> 
> It's already essentially enabled unconditionally. PAGE_SHIFT will always 
> be 13 on sparc64 systems.

I see.

I was confused by this comment:


/* Flushing for D-cache alias handling is only needed if
 * the page size is smaller than 16K.
 */
#if PAGE_SHIFT < 14
#define DCACHE_ALIASING_POSSIBLE
#endif

My thinking was that there might be a flush skipped when using transparent
huge pages which causes these crashes.

> The flushing should be happening for folios of any size. See 
> flush_dcache_folio(()/flush_dcache_folio_all().

OK, I'll have a look and maybe add a printk() there.

> You could try setting page_poison=1 on the kernel command line to see if 
> the kernel detects any freed pages being used.

Ah, good to know. Thanks.

> Is this a different Cheetah+-based system than the one I borrowed? 
> Definitely some sort of memory corruption happening, but the system I 
> used seemed much more stable than this.

Yes, it's the same Sun Netra 240. It has been running stable for days, but
upgrading to the latest systemd version caused these new reproducible crashes
which started my new investigation.

Replacing "call cheetah_patch_copyops" with "call generic_patch_copyops" did
not help in this situation which indicates that the bug is not in Michael's
patch set which is a good sign at least for Michael's work.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913