Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support (fwd)

[gnats-admin%netbsd.org@localhost]

The following reply was made to PR kern/58225; it has been noted by GNATS.

From: Paul Goyette <paul%whooppee.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
 (fwd)
Date: Fri, 23 Aug 2024 18:45:03 -0700 (PDT)

 Logging feedback to the PR audit trail
 
 +---------------------+--------------------------+----------------------+
 | Paul Goyette (.sig) | PGP Key fingerprint:     | E-mail addresses:    |
 | (Retired)           | 1B11 1849 721C 56C8 F63A | paul%whooppee.com@localhost    |
 | Software Developer  | 6E2E 05FD 15CE 9F2D 5102 | pgoyette%netbsd.org@localhost  |
 | & Network Engineer  |                          | pgoyette99%gmail.com@localhost |
 +---------------------+--------------------------+----------------------+
 
 ---------- Forwarded message ----------
 Date: Thu, 22 Aug 2024 19:09:31 -0700 (PDT)
 From: Paul Goyette <paul%whooppee.com@localhost>
 To: thorpej%netbsd.org@localhost
 Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
      (fwd)
 
 Can you look into this please?
 
 From what I can see (*) you've handled the (COMPAT_NETBSD32 & COMPAT_16)
 situation, but at the expense of mishandling (COMPAT_NETBSD32 & ! COMPAT_16) 
 situation.  You really should not be auto-loading a module
 that isn't desired.  As you can see, that brings in a whole lot of other
 cruft for COMPAT_* and COMPAT_NETBSD323_*.
 
 What happens if we simply don't autoload compat_netbsd32_16 module?  If
 it is loaded through other means (modload(8) maybe) then we get the
 behaviour that you already implemented; if the module isn't loaded, we
 should reurn EINVAL.
 
 Is there some way to "ask" an executable if it needs the module, and
 then _selectively_ autoload it?  Today the autoload is rather heavy
 handed and happerns for way too many executables (ie, any 32-bit
 executable from NetBSD-9, according to PR submitter).
 
 I'd also like to rethink the lock-the-module stuff but that can maybe
 wait a bit.
 
 Thanks.
 
 [*] "see" is difficult for me these days, having suffered almost daily
 from insomnia for the past year.  There may well be details and nuances
 that my sleepdeprived gray cells have missed.  Feel free to point them
 out!
 
 +---------------------+--------------------------+----------------------+
 | Paul Goyette (.sig) | PGP Key fingerprint:     | E-mail addresses:    |
 | (Retired)           | 1B11 1849 721C 56C8 F63A | paul%whooppee.com@localhost    |
 | Software Developer  | 6E2E 05FD 15CE 9F2D 5102 | pgoyette%netbsd.org@localhost  |
 | & Network Engineer  |                          | pgoyette99%gmail.com@localhost |
 +---------------------+--------------------------+----------------------+
 
 ---------- Forwarded message ----------
 Date: Tue, 20 Aug 2024 18:10:54 -0700 (PDT)
 From: Paul Goyette <paul%whooppee.com@localhost>
 To: gnats-bugs%netbsd.org@localhost
 Subject: Re: kern/58225 - netbsd9/amd64 requires COMPAT_16 for 32bit support
 
 OK, I think I've got this understood now...
 
 The changes that were made in compat_netbsd32_signal.c rev 1.53 and 1.54
 are just plain wrong.  These changes cause every netbsd32 image to load
 all of the compat code all the way back to _16.  This is a "backwards
 dependency" where -current depends on older code;  a correct ordering
 would be having the older code depend on the newer (as can be seen in
 all the MODULE(compat_netbsd32_*) modules' required-lists.
 
 IMHO the right thing to do would be to move the relevant code out of
 src/sys/compat/netbsd32/netbsd32_compat_16.c and into
 src/sys/compat/netbsd32/netbsd32_signal.c  That would leave only
 the machdep code for sigreturn14.  (The module init/fini changes in
 rev 1.5 should remain, too.)
 
 As a result, signal code will have everything it needs without using
 a reverse-dependency.  It also simplifies things by removing the need
 to keep track of the *_valid stuff.  (It also removes the need to
 prevent any unload of the compat_netbsd32_16 module - the stuff using
 ``p->p_lflag & PL_SIGCOMPAT''.)
 
 A reproducer for the problem should be simple.  First you modload
 the compat_netbsd32 module.  Then run an image that uses the module
 (preferably a 32-bit netbsd-9 or earlier).  Observe with modstat(8)
 that all compat_xx and compat_netbsd32_xx modules have been loaded.
 
 
 +---------------------+--------------------------+----------------------+
 | Paul Goyette (.sig) | PGP Key fingerprint:     | E-mail addresses:    |
 | (Retired)           | 1B11 1849 721C 56C8 F63A | paul%whooppee.com@localhost    |
 | Software Developer  | 6E2E 05FD 15CE 9F2D 5102 | pgoyette%netbsd.org@localhost  |
 | & Network Engineer  |                          | pgoyette99%gmail.com@localhost |
 +---------------------+--------------------------+----------------------+