Re: port-hppa/56867: hppa: intermittent SIGSEGV reports in t_ptrace_wait's stepN and setstepN test cases

[Tom Lane <tgl%sss.pgh.pa.us@localhost>]

The following reply was made to PR port-hppa/56867; it has been noted by GNATS.

From: Tom Lane <tgl%sss.pgh.pa.us@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-hppa/56867: hppa: intermittent SIGSEGV reports in t_ptrace_wait's stepN and setstepN test cases
Date: Thu, 09 Jun 2022 01:39:23 -0400

 I've managed to resurrect my NetBSD/hppa installation, and resumed
 investigating this issue.  My theory that there's something wrong with
 ITLBMISS processing seems to be backwards: after adding some hacky
 instrumentation, I found that the test passes when an ITLBMISS trap
 occurs upon trying to execute the modified instruction stream, while
 it fails when one does not.  That led me to guess that what's missing
 is a TLB flush operation, and sure enough this quick-hack patch seems
 to fix it:
 
 Index: sys/arch/hppa/hppa/pmap.c
 ===================================================================
 RCS file: /cvsroot/src/sys/arch/hppa/hppa/pmap.c,v
 retrieving revision 1.117
 diff -u -r1.117 pmap.c
 --- sys/arch/hppa/hppa/pmap.c   26 May 2022 05:34:04 -0000      1.117
 +++ sys/arch/hppa/hppa/pmap.c   9 Jun 2022 03:36:33 -0000
 @@ -1874,9 +1874,12 @@
  pmap_procwr(struct proc *p, vaddr_t va, size_t len)
  {
         pmap_t pmap = p->p_vmspace->vm_map.pmap;
 +       pa_space_t sp = pmap->pm_space;
  
 -       fdcache(pmap->pm_space, va, len);
 -       ficache(pmap->pm_space, va, len);
 +       fdcache(sp, va, len);
 +       ficache(sp, va, len);
 +       pdtlb(sp, va);
 +       pitlb(sp, va);
  }
  
  static inline void
 
 This is mainly based on observing that most other calls of ficache()
 are associated with pitlb() calls.  I found two exceptions:
 
 kobj_machdep.c's kobj_machdep() does ficache() but lacks pitlb().
 pmap.c's pmap_syncicache_page() the same.
 
 Perhaps those are also wrong?  I lack any evidence of actual problems
 with them, but I'm wondering.
 
 Another point is that some other places in pmap.c use
 
 #if defined(HP8000_CPU) || defined(HP8200_CPU) || \
     defined(HP8500_CPU) || defined(HP8600_CPU)
 
 around pitlb() calls, though that is far from universal.  Since
 I'm testing on HP8500, my results prove nothing about whether
 it'd be OK to use a similar #if in pmap_procwr().
 
 In combination with previous fixes, this brings me to a point
 where t_ptrace_wait passes cleanly (modulo one expected failure).
 Its siblings t_ptrace_wait* seem to have a residual problem or two.
 
 For the record, this is with a kernel built from HEAD/202206081310Z,
 but my userland is still from 202206030100Z.
 
 			regards, tom lane