From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37876 invoked by alias); 27 Feb 2019 16:24:42 -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 37468 invoked by uid 89); 27 Feb 2019 16:24:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=wait! X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.134) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 27 Feb 2019 16:24:06 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MderZ-1hYMgU2UXR-00Zg5k; Wed, 27 Feb 2019 17:24:03 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 11138A807D3; Wed, 27 Feb 2019 17:24:03 +0100 (CET) Date: Wed, 27 Feb 2019 16:32:00 -0000 From: Corinna Vinschen To: "E. Madison Bray" Cc: cygwin@cygwin.com Subject: Re: Consider exposing mmap_is_attached_or_noreserve Message-ID: <20190227162403.GD4133@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: "E. Madison Bray" , cygwin@cygwin.com References: <20190227161712.GB4133@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WjWU9mUuKzTKEtBb" Content-Disposition: inline In-Reply-To: <20190227161712.GB4133@calimero.vinschen.de> User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-02/txt/msg00485.txt.bz2 --WjWU9mUuKzTKEtBb Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2599 On Feb 27 17:17, Corinna Vinschen wrote: > 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. >=20 > 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 :} Oh, wait! Maybe there is a simple solution. Patch 9a5abcc896bd added a single line exception protect; to the pthread::thread_init_wrapper method. What if adding the same line to the altstack_wrapper function would help for altstack as well? Can you test this? Thanks, Corinna --=20 Corinna Vinschen Cygwin Maintainer --WjWU9mUuKzTKEtBb Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlx2uaIACgkQ9TYGna5E T6ATKBAApikct14V/VbMCTbQs5RVb8QEeoOmz7NG1rrdEBMMgyZaVQiQhIXJiclP X7YWBbnuTxKJRABu4RLAF5q9gpMtL00tJFxIsThWtMSXSGLtzlkT6bv0lS+ERSkJ r34udbBxtF+ADtr6OZFUmXW8oVm6bke/065hc7fqFzRtk5Onu2O0OIuIN3lOjyEE 7czioOwBOLtdYaOy8EHxK1sdB8i8xisLQsGQ4DFX4tT4bm/CaQdI5TB5SBQV6u5H w0s5FuxZbpRSCaFyZea6j9mza/o3us4V+6hhrZj7hQpdCAbsMNOqPsquA04aiAnR 4raO0neLVXrD5wPE4eF7EB7ZwwyuA+pR4WHzW633B+FVnHhrbfRfgNRV3mjQdnEc TOLl00DG7jW4JBXK66O86dY4hRlU3z7iGu8PStQe2r4KIC6rU8FDnrNHf8G3q2rd OcvzHMBAcLLdxtF8km7AP/SCfMhjIezWfjMFwmo8T1EtbQrJ1WFcgzLW8sLBoeVs LUeIW4dBWCyTBkH5zmvroKyD47vkasdiIbqDIN0Ujsyw3AAlJqQ6KAnPlgUQ735J 1Z7TDhnx+kDE1vqXnN1hodv68jcyHhFP1kp/3vnk8QkgKrk5Q9I0Te1TA6Otn2cv jRXV7eJ7pkQXsgBT9cbvPEgzIobCUQy7F/DHlXzw8qKO/KiP8FA= =9VTY -----END PGP SIGNATURE----- --WjWU9mUuKzTKEtBb--