From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) by sourceware.org (Postfix) with ESMTPS id EB2273858284 for ; Wed, 15 Feb 2023 13:41:21 +0000 (GMT) Authentication-Results: sourceware.org; dmarc=permerror header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPSA (Nemesis) id 1N2Dks-1oPiXg34jG-013ft0; Wed, 15 Feb 2023 14:41:18 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 1B0C2A81B74; Wed, 15 Feb 2023 14:41:18 +0100 (CET) Date: Wed, 15 Feb 2023 14:41:18 +0100 From: Corinna Vinschen To: cygwin@cygwin.com Cc: w6b7rk5yu4mt25v3 Subject: Re: Fw: Re: Why do these mprotect always fail? Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com, w6b7rk5yu4mt25v3 References: <0Qjpbo0t_1WTd9--kVw5gLR1PdJzG7myKYzhxdzDIqnWYwLnywFCtSbekykskWViaSJM_bcLQBEFT_wg4-IApgEYrX5bHFIZH7Ro40oDYGs=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0Qjpbo0t_1WTd9--kVw5gLR1PdJzG7myKYzhxdzDIqnWYwLnywFCtSbekykskWViaSJM_bcLQBEFT_wg4-IApgEYrX5bHFIZH7Ro40oDYGs=@protonmail.com> X-Provags-ID: V03:K1:fzG7LZ8b3jbvj4s5pqrto04ZYJEoapaK5fkL9FE5sZ60yorNt8g POoMmBHwxiURNp4B4w5loVPayUo+ypyO4hxCnpV9gy3XschmixbQ+ad4YiUnb5I4Be62T4k npCZ/laHi1k7TSMeEgtgLLH+MjYQMX/oiZnUvbbIJwH4rysUV45dhU3MXghH6VUGOKy8cy2 vjPylK/uub1N+5xcXhKKA== UI-OutboundReport: notjunk:1;M01:P0:NVakbL3FsjU=;VRDdAGKxfdizyJTksl94g4OI4wU eJJd2UxNRSOxCDlLmzXlHNmU6SxE66EHVR5bKDJitiLJQu/Bu9ACkSFT4x8/0rOnLKaqAQHU1 wAbzCuQrWh/5C2kh9h4PhrfJKlDJOdOKKmZZUzKunZkoZvy8FrlVPWjMh15IlhHm0oS8VCVLC BnBW3lSNvT9wdGDxSK5ICCPVa8RsykkefVegiuZS1lCKhEbHa9D+KrwQ16Je62EGTtFzUXNfY yOGPOQBQMx74Wrx2h0Z6DIHb3Tn/En7Ok428TI7rHARfzDQc5LZrMANorfhrgEEALiCZEpzCb /C8MIyxokaFa9zYeRQ7coRgeIoQUMgiWp0KNvEFsLMPs/FklNuYzf5q9alOLFu3WvlzXOghMg vgum2NUiwnTCj1FK0cf77T8I6su2pxTMa5c2sW23rORO65Ehm2PqE/nUPxpJxE9l6W6G9mFGk VI5d1nAAtZwxBtcnKQYaAqf6E+hWQA+hSm+WhWSpaNY+XzNIpI+YeNHre8c0W0ODjJOrLrhsk PUmWdgpU3nM3NjHG7ICmxfy6dnP+PKeQbVAhR7cezO8J/NCOAmux52hibVApCkeUNqOI6bcs/ hxuhhS2vQPp+k6dAbyJ0GzwmT8VH6oj8fKcpI9qNZXCte26w3gs/vMn4YvOjABWjCvwyWeNHp d+iL5NDOrc0jJbRptWY5U/0lID4t91t19eD75CewGg== X-Spam-Status: No, score=-97.4 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_FAIL,SPF_HELO_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Feb 15 12:40, w6b7rk5yu4mt25v3 via Cygwin wrote: > On Wednesday, February 15th, 2023 at 19:13, Corinna Vinschen wrote: > > On Feb 15 11:14, w6b7rk5yu4mt25v3 via Cygwin wrote: > > > Corinna Vinschen wrote: > > > > > > > cygwin-developers is for developers woking on Cygwin itself, not for > > > > developers using Cygwin to develop something else. I dropped the ML > > > > from the recipient list. > > > > > > > > And please don't top-post. Thanks. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > [...] > > You're misunderstanding what PAGESIZE or PAGE_SIZE means. It's the > > system page size used for mappings, and it's a fixed value defined by > > the system and provided to you by the system headers and, especially, > > sysconf(_SC_PAGE_SIZE). > > > > It's NOT something you can just change and think the result will still > > work. Especially given that mmap doesn't know that you changed a macro > > in your application code... > > > > > The problem is Cygwin > > > is not fine with the particular value 4096 but the program needs the > > > value to be exactly 4096. > > > > > > Sorry, but that can't work. If the program actually demands it, it's > > non-portable. > > You misunderstood what I said. > > It's really just a naming conflict and a coincident. On the context of > the source code (it's an interpreter), PAGE_SIZE is indeed > JIT_PAGE_SIZE (not the system page size, but the page size defined > internally by the interpreter). On Linux, the name doesn't conflict. > On Cygwin, I found on limits.h and cygwin/limits.h already defined > PAGE_SIZE so it caused a naming conflict: > > #define __PAGESIZE 65536 > #define PAGESIZE __PAGESIZE > #define PAGE_SIZE PAGESIZE > > But the problem not related to the naming conflict. If I renamed > PAGE_SIZE to JIT_PAGE_SIZE, the problem is still there. The problem is > Cygwin will not work with JIT_PAGE_SIZE = 4096. Please have a look at > the code I posted. It will always error with "Unable to mprotect". Again, it doesn't matter what your application is doing with PAGE_SIZE. PAGE_SIZE in limits.h is a read-only value to inform your application about the system page size. Just because your application overwrites PAGE_SIZE doesn't change the fact that the system's mmap uses the real page size, i. e., 64K. Look, let's make a Windows example: Somewhere in the headers there's a definition # define MAX_PATH 260 This defines the maximum path length when using the Windows ANSI File API, for instance, CreateFileA(). Now you go ahead and overwrite this value in your application: #undef MAX_PATH #define MAX_PATH 1024 Do you really think that the Windows functions will even notice that you changed MAX_PATH in your application and they will suddenly happily work with 1K paths? No, they won't. And it's, hopefully obviously, the same with mmap and mprotect. Just because you define your own PAGE_SIZE value doesn't mean the system will even see this. It will continue to use the real page size value, as returned by sysconf(_SC_PAGE_SIZE), and mprotect will fail if the address isn't given in multiples of sysconf(_SC_PAGE_SIZE). Corinna