Re: kern/53261: kernel crash during test run

[Kamil Rytarowski <n54%gmx.com@localhost>]

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

From: Kamil Rytarowski <n54%gmx.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/53261: kernel crash during test run
Date: Wed, 23 May 2018 15:44:59 +0200

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --y79mPGDBIgKaDhvzdptHaxGCfI4KTIVdL
 Content-Type: multipart/mixed; boundary="rIpiejDKqQ4POgO3wbiRA1na5QpAIN8B2";
  protected-headers="v1"
 From: Kamil Rytarowski <n54%gmx.com@localhost>
 To: gnats-bugs%NetBSD.org@localhost
 Message-ID: <41221e88-2235-cecc-edb2-b23def39d871%gmx.com@localhost>
 Subject: Re: kern/53261: kernel crash during test run
 References: <pr-kern-53261%gnats.netbsd.org@localhost>
  <20180523132001.B98377A21F%mollari.NetBSD.org@localhost>
 In-Reply-To: <20180523132001.B98377A21F%mollari.NetBSD.org@localhost>
 
 --rIpiejDKqQ4POgO3wbiRA1na5QpAIN8B2
 Content-Type: text/plain; charset=utf-8
 Content-Language: en-US
 Content-Transfer-Encoding: quoted-printable
 
 On 23.05.2018 15:20, Martin Husemann wrote:
 > The following reply was made to PR kern/53261; it has been noted by GNA=
 TS.
 >=20
 > From: Martin Husemann <martin%duskware.de@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:=20
 > Subject: Re: kern/53261: kernel crash during test run
 > Date: Wed, 23 May 2018 15:16:04 +0200
 >=20
 >  On Wed, May 23, 2018 at 01:10:01PM +0000, Kamil Rytarowski wrote:
 >  >  This code works reliably on i386 in 32-bit mode. This includes more=
 
 >  >  advanced sanitizer ASan that allocates a lot of memory.
 > =20
 >  Doing something like:
 > =20
 >  	void *p =3D syscall(SYS_mmap, 0, 4, PROT_WRITE, MAP_PRIVATE,
 >  	    fileno(f), 0);
 > =20
 >  may work by pure chance on some ABIs, but it *NEVER* is the right thin=
 g
 >  to do.
 > =20
 >  So making syscall() fail if passed SYS_mmap is a good thing, IMHO.
 > =20
 >  Martin
 > =20
 >=20
 
 I agree that this is not the optimal solution.
 
 C programs shall use libc call.
 
 Special cases like Golang want to use syscall/__syscall, because it's
 very convenient. It's so convenient that they were switching for example
 from assembly implementation of pipe(2) to syscall(2) approach and
 emulating pipe(2) with pipe2(2).
 
 https://github.com/golang/go/commit/eab06e65f7c4a1e3acafc220d0e9b8eca50f0=
 311
 
 Blacklisting these syscall break compat and perhaps existing programs,
 for example in Golang ARM:
 
 =2E/zsyscall_netbsd_arm.go:       _, _, e1 :=3D Syscall6(SYS_FTRUNCATE,
 uintptr(fd), 0, uintptr(length), uintptr(length>>32), 0, 0)
 
 and Golang I386:
 
 =2E/zsyscall_netbsd_386.go:       _, _, e1 :=3D Syscall6(SYS_FTRUNCATE,
 uintptr(fd), 0, uintptr(length), uintptr(length>>32), 0, 0)
 
 Syscall6 is a wrapper for RawSyscall that is a wrapper for syscall(2).
 
 
 We should just fix the ARM panic and be done with it.
 
 
 --rIpiejDKqQ4POgO3wbiRA1na5QpAIN8B2--
 
 --y79mPGDBIgKaDhvzdptHaxGCfI4KTIVdL
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"
 
 -----BEGIN PGP SIGNATURE-----
 
 iQJABAEBCAAqFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAlsFcFwMHG41NEBnbXgu
 Y29tAAoJEEuzCOmwLnZsb/wQAInu48XpZJ/EcJrPkB4dwpwahVo5prYlldUtrWRc
 26z2JhFj48IDSU/lTWF7C+YLmato4OGSK982WMgcuzDGLoa/TimxdTHylft1wuK2
 yNAn8oixKFgCyDLhuVtpBbJ7SpodlSTXTgXLEA77F9tl8+5OcD5TIAtaITDPyAI4
 +r8OLAD73Rz1N8hdmUWWScwSBqIlMizCUlbskK63ZHmUxUQUmzJLPci2Gr0r3LiC
 0gOVnqCnstlFpHbFkoc43qrVUyenXYmbTq16ToYdv0JpPmIvV/LVXnz7w8bV6Qsl
 AqbSEQiZf2JkZSQcHn9KP6AfRcrT1TLZoyKAAWo/p1E4X5Ujg7NrfyunkP/yhfQB
 FWAxMqN0Di7K3/9YtzKoL/rvI5drlY3pudAjAP6NMp+icaYLyukezgn2zI0sKVgA
 VEh6WZxraPavNjbmeNTB5y/1g+fmJDKFQfmvhJddccY8qERGLkhD3eKCqldHeS5g
 N2aAbSKxiv8B8eR9EH6hsnixuFDS6d1kCtG+3QACiQMa25lmWGess3/dSGuok6DN
 Or+d8lmSf1ADjJEHMV00axSNUt/s6hrHz5QtJTCyY4rrizA4lPuW7ek3FG8FXa4b
 CMD5PaOr0vzupCmYx+w1hLhNjacSkwrJunFuaQL/XveUHfS0KES7Ct77NUZGDyMa
 6I1v
 =mp8s
 -----END PGP SIGNATURE-----
 
 --y79mPGDBIgKaDhvzdptHaxGCfI4KTIVdL--