DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=PnM9FgK8HQkf+e6dCa2nkZk7dTlD/wByYq4JkMD5LcHnlk3kIsFln
	9snFlnfKIi7rMiGN0t+vJpTVt7LElBChqGIIrLikjYsRTvzfmrqXIOg498dgmlnG
	V/vV5IYeA6BK8yzt63ZCT9Uop/odgvbJ2q0QKxzf58uRoaIWzgQyI8=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Wed, 27 Feb 2019 17:17:12 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: "E. Madison Bray" <erik DOT m DOT bray AT gmail DOT com>
Cc: cygwin AT cygwin DOT com
Subject: Re: Consider exposing mmap_is_attached_or_noreserve
Message-ID: <20190227161712.GB4133@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: "E. Madison Bray" <erik DOT m DOT bray AT gmail DOT com>,	cygwin AT cygwin DOT com
References: <CAOTD34a-hdE0Jx=7HjB3CMYqgVr6m7Xo39YcmjeL0=43Opjkjg AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="8N0TQpGUCeEQshoq"
Content-Disposition: inline
In-Reply-To: <CAOTD34a-hdE0Jx=7HjB3CMYqgVr6m7Xo39YcmjeL0=43Opjkjg@mail.gmail.com>
User-Agent: Mutt/1.11.3 (2019-02-01)

--8N0TQpGUCeEQshoq
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Feb 27 16:38, E. Madison Bray wrote:
> Hello,
>=20
> A very technical request regarding Cygwin internals: In mmap.c there
> is a function mmap_is_attached_or_noreserve(void *addr, size_t len)
> which is called from Cygwin's exception handler in the case of a
> STATUS_ACCESS_VIOLATION.
>=20
> This is called in case an access violation occurs in memory that was
> allocated with Cygwin's mmap() with the MAP_NORESERVE flag, and allows
> us to commit the relevant pages when they are accessed.
>=20
> After a successful call of mmap_is_attached_or_noreserve(), the Cygwin
> exception handler returns with ExceptionContinueExecution.
> Unfortunately, if the application happens to have a Vectored Continue
> Handler registered which happens to do something in the case of
> STATUS_ACCESS_VIOLATION (see [1]) there is no obvious way to tell if
> we're handling this sort of case.
>=20
> Normally this isn't too much of a problem: E.g. we could just check
> the address that caused the access violation and see if its status is
> now MEM_COMMIT (i.e. Cygwin ran its exception handler and all is
> good).  However, due to the bug described in [1], if an exception
> occurs in code running on a sigaltstack, the Cygwin exception handler
> isn't run.
>=20
> This makes for a tricky to handle use case:  What if some code in a
> signal handler function tries to access uncommitted memory in a
> MAP_NORESERVE mmap?  It's probably an unusual, undesirable case, and I
> haven't personally encountered it *yet*, but I could imagine some
> cases where it might happen.
>=20
> In order to handle such a case it might be nice if
> mmap_is_attached_or_noreserve were able to be called by user code,
> perhaps as a new cygwin_internal(...) call.  I'd happily provide a
> patch, but I fear this might be an X/Y problem that I'm not seeing.

Honestly, I'm not overly keen to expose this stuff.  Wouldn't it
make more sense to fix Cygwin's sigaltstack implementation to handle
these cases gracefully?  You're apparently not shy working with
Windows exception handling.  Patches more than welcome!  I'm not
happy not having found a solution to this problem :}


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--8N0TQpGUCeEQshoq
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlx2uAgACgkQ9TYGna5E
T6ACyA/+NVP5Hec7XQdiLwwExFU4MFAhFzXyWkosj1rRW94a+9QgkYNH8ZPUnoKD
g/NlPZRvzMeQgHEQlgiYsqKo9LP3y1I9xGofeG13Lm+5InjO5iHDQv/BpfP/fCxO
ZJ1IGbvNS6tc5gDilxKrQv4lZ4GBBjlpKQSR7FZ7swycN76qDNdW6ruGb1J6yWpY
4eeTWT0uzBFMrKlKNPCyrKSKZCJ6CAAAkQmPmBsIXwbH8s4lv9AVHJbclnsnlJVh
zUUtpnxa5E1THSw9WdG+YYDjNuxQfC9Q174CILfVN6p7Z3NLhSPn1L8s4VmjHXYq
Yd3Q247k0AvfFdEmrhpmy3pQDVqeQahYu2C0J5llIA+7z9HlCy3Ww3jKyWIQbpGK
On3KdXG+L6/ZeiWEC+gupSpLn19onNyHaJ1GQKaf4R7JG49rxksRqOGSaEYypNjl
EBW/y0633YAv0CL2YVi+/9AObaXWGnqvHWcU0NQ+K7tHIeqsDC7VPkMOY1GvkoqI
QpxrhiE7P3ng2aJL842y41aP2z2JvXEXabYtVpSE2vUWrFDRhoNLsbmRf55jMjfU
TAEntvug09ltNCnleD1Y510PGr+Kw2KyeBxlcOZXcl+pPs3dsBZEwu1dZI1L3pV+
/W7McXjHgyr0efmLeDfHVcj4LnxKuttqoZqSNFjOQ3WPProIByc=
=YFpc
-----END PGP SIGNATURE-----

--8N0TQpGUCeEQshoq--