X-Recipient:	archive-cygwin AT delorie DOT com
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=wOYvFK3TybkY+RJMGPTeS9MGq1NFaXmWCYmzjEYYbSttPm1yVfQOZ
	vm3186n4unZev/5/liep9rD16u+9AI5UBV2Vv4WJp63ovrr8dZbwFUTe4i1EVHDz
	enSddnMX5mqK+at9ArHXY5V+1CeUu/3jetMPsD0/VsSzKske+I0WwM=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; 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; s=default;
	bh=vsjB2l9UYXKN7B9oF2pColPJFZ0=; b=KBomKXnCIlVaevBhrmTv1nCirqS0
	BbKgbL/ViVPSWGI46JRVMihKFxxGBVnMRm2aBlIgMH2UEJ5n+4r+E5Z2ON7VWa/8
	7WWjm6pZO5kDe2mt2SdSEaG9MxUe/Lllvywa1h0lYSrvXyfPhQwBB4lAbzWwanXf
	WomRJq6prou/zlI=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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
Date:	Wed, 27 Feb 2019 17:24:03 +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:	<20190227162403.GD4133@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> <20190227161712 DOT GB4133 AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
In-Reply-To:	<20190227161712.GB4133@calimero.vinschen.de>
User-Agent:	Mutt/1.11.3 (2019-02-01)

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

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"

-----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--

- Raw text -