From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64151 invoked by alias); 27 Feb 2019 16:17:17 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 63755 invoked by uid 89); 27 Feb 2019 16:17:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-100.9 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=shy, personally X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.17.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 27 Feb 2019 16:17:16 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MCayD-1gpvMB3u5b-009kQQ; Wed, 27 Feb 2019 17:17:13 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 5381BA807D3; Wed, 27 Feb 2019 17:17:12 +0100 (CET) Date: Wed, 27 Feb 2019 16:19:00 -0000 From: Corinna Vinschen To: "E. Madison Bray" Cc: cygwin@cygwin.com Subject: Re: Consider exposing mmap_is_attached_or_noreserve Message-ID: <20190227161712.GB4133@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: "E. Madison Bray" , cygwin@cygwin.com References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8N0TQpGUCeEQshoq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-02/txt/msg00483.txt.bz2 --8N0TQpGUCeEQshoq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2195 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" Content-length: 833 -----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--