From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122241 invoked by alias); 4 Jun 2019 14:49:55 -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 122215 invoked by uid 89); 4 Jun 2019 14:49:53 -0000 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 Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.130) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Jun 2019 14:49:51 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.167]) with ESMTPSA (Nemesis) id 1N2m7Q-1gZeBk39SO-0133FR; Tue, 04 Jun 2019 16:49:48 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 1843FA80667; Tue, 4 Jun 2019 16:49:48 +0200 (CEST) Date: Tue, 04 Jun 2019 14:49:00 -0000 From: Corinna Vinschen To: Stanislav Kascak Cc: cygwin@cygwin.com Subject: Re: possible problem with memory allocation using calloc/mmap/munmap Message-ID: <20190604144948.GT3437@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: Stanislav Kascak , cygwin@cygwin.com References: <20190603115456.GG3437@calimero.vinschen.de> <20190604131836.GS3437@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="daC8KDjlMyCcZyAo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-SW-Source: 2019-06/txt/msg00027.txt.bz2 --daC8KDjlMyCcZyAo Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2998 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" Content-length: 833 -----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--