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=ACfENTUzd0ZDs7/AxOPh/2F2ZxFy0YhM/RNAeV2tjymghF930goAy
	Nyl020l6xnYU/Fp+t2zQ1B6sWGgsA4/SAx0wl3lQXR6dPBmi4p6vkf6nmK2455bu
	qOVCBGsWDi3SEUCweEfJfCxvzDWPcBOendOdWw03IejxGNn3LvnO78=
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=O3rnZMtDlHJMZgzGR5UFH+TvYMs=; b=WFNSvuADRAGzw3QQ/5IRhDwqNB8V
	SR6q+wlKkYJgSUOied/Ucfw5WIA6AzRPL1E6Rxf6rl5hOS2i3OpBfYSuxRm72T2y
	LP6Z1FAY7+/IRHYe2nX72IJgmJhE/4tY59MABOMOLjN4FpLi9OB/9Wk0uFHwFDjU
	ugKRZg3k5rG247o=
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=-102.1 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,RCVD_IN_DNSWL_NONE,UNSUBSCRIBE_BODY autolearn=ham version=3.3.1 spammy=arise, H*F:D*cygwin.com
X-HELO:	mout.kundenserver.de
Date:	Tue, 4 Jun 2019 16:49:48 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	Stanislav Kascak <stanislav DOT kascak AT gmail DOT com>
Cc:	cygwin AT cygwin DOT com
Subject:	Re: possible problem with memory allocation using calloc/mmap/munmap
Message-ID:	<20190604144948.GT3437@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	Stanislav Kascak <stanislav DOT kascak AT gmail DOT com>, cygwin AT cygwin DOT com
References:	<CALLhcm4QGY+eP0_CRiSbJwQ12kOetvTK=6-AtC17x7d+QhGKTw AT mail DOT gmail DOT com> <20190603115456 DOT GG3437 AT calimero DOT vinschen DOT de> <CALLhcm4qaha=XuBWEqag7QH1veA82UrB94emFtFMd26dZ_ZGZQ AT mail DOT gmail DOT com> <20190604131836 DOT GS3437 AT calimero DOT vinschen DOT de> <CALLhcm4sHGmFwki+RuUOUA-GfnXzmOUX4Tr8Es-=291Bo+A4dg AT mail DOT gmail DOT com>
MIME-Version:	1.0
In-Reply-To:	<CALLhcm4sHGmFwki+RuUOUA-GfnXzmOUX4Tr8Es-=291Bo+A4dg@mail.gmail.com>
User-Agent:	Mutt/1.11.3 (2019-02-01)

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

On Jun  4 15:48, Stanislav Kascak wrote:
> > > > > It seems that when mmap() is called with length argument exceeding
> > > > > size of file, only memory to fit that file is allocated. munmap()
> > > > > however frees the full specified length. [...]
> > > > [...]
> > > > I know this situation is unsatisfying, but I have no easy workaround
> > > > to allow this.  Cygwin could add the anonymous mapping on the next
> > > > 64K boundary on 64 bit, but that would result in a hole in the mapp=
ing
> > > > which seemed like a rather bad idea when porting mmap to 64 bit.
> > > >
> > > > Ken's also right that munmap is doing the right thing here.  If
> > > > anything's wrong, it's mmap's workaround for mappings beyond the fi=
le
> > > > length.  If only 64 bit would allow 4K-aligned mappings :(
> > >
> > > Thanks for the answer. It is appreciated.
> > > I understand the problem and difficulty to resolve it. Maybe returning
> > > an error from mmap (and putting a comment to code for its reason)
> > > would be sufficient. mmap caller could just adjust requested
> > > allocation size to file size. Without error, caller has no way of
> > > knowing memory was not allocated and segfault is then thrown in an
> > > unrelated memory segment which makes the root cause hard to track
> > > down. But, I do not know all the implication that could result from
> > > that, so evaluation of this approach is up to you.
> > [...]
> > Eventually Cygwin adds another mapping to fullfill the entire mapping
> > request:
> >
> >  |-- file 4K --|-- filler 60K --|-- filler 192K --|
> >
> > The problem on WOW64 and real 64 bit is that it's impossible to map
> > the first filler.  However, this area in the VM will *never* be
> > allocated by other application functions due to the allocation
> > granularity of 64K!
> >
> > So my workaround for 64 bit and WOW64 is to just skip allocating the
> > first filler:
> >
> >  |-- file 4K --|-- THE VOID 60K --|-- filler 192K --|
> >
> > The advantage is now that the following munmap of 256K will only
> > unmap the map for the file and the filler, but not the region you
> > calloced before, which formerly was accidentally mapped to the
> > filler region.  This just can't happen anymore now.
> >
> > Would that be feasible?  If so I can push my patch and create a
> > developer snapshot for testing.
>=20
> Two questions arise when I'm thinking about workaround solution:
> - what happens if caller tries to write to |-- THE VOID 60K --|. Since
> this is unallocated, would there be a segfault?

Accessing the VOID would raise SIGSEGV, while accessing the filler
raises SIGBUS.  The latter is also used to implement MAP_NORESERVE,
which the VOID can't support.

> - is it possible that some subsequent mem alloc request would return
> region from |-- THE VOID 60K --| which could again cause segfault
> after munmap?

No, as stated above.  Allocations are restricted to Windows' 64K
allocation granularity.


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

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

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

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlz2hQsACgkQ9TYGna5E
T6DbxBAAo3LRnyk59sxy+yFfE0jglV5fhDFfWXK1cGl7Tk83SNc4uojjcv/qbWD3
o25TVRreQ4Gx8CG4kpqpnYfPsviRI/llRZajJZHT041xAVnRqlWL3PcGXHr5MO8w
hCksNQcCBE8aFDyrQgRkSkoYO3FyPsOlLCpmL8Mh+1mlmvkPZucSTJoEdh5uO5wY
HR7Q0GCtV0jEyuxXBFRMpe34fUSRaCQf7jn6gMePDc7SHtpYDHPLLom0Jw1xYMXB
bXCj/GoVsKeXkYcFhSikND/cwT/PNmPQosoxc3M4Kl0wMcny5gqnwCeKWvfKUjA8
yP3GEUMGMGhFV8T+f2uJJDZs7gTMLBIgVGdMRuAU56084mVqt7BnB4mnnjk9yWrm
FCAaC+vR+DsvNbXoqQyVSgSzh01VCOurqZa3d3sEYdmHG6flADpMbscXJOiD0lop
qUyMpEZ0UuKolesJ7mtGATbbQfhSi8gxkubFZTv9ip7WujgRMIwUJmMZJE8ir55w
gK/P7rgzBjPqdeuFw2WWADZHRKJHvEEQhGSR1nNc5ckwaZZVlCoUhCrbf/UDae+H
H2skq7kRDsFshKq4yix3sh6JXwNxdBNkGOaY+2FSiZaM0snf+73OQt9E40BsZodK
WcR5ekYtxzf9rPrJMlW4q4rFdKwHg18jh15UDY+8UG+m0rFMzRk=
=h5aP
-----END PGP SIGNATURE-----

--daC8KDjlMyCcZyAo--

- Raw text -