X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 2CAD63858284
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1676468500;
	bh=yj5uusU4iEyZzMKdqm26xNUYocG3eUneonXT/NZLa9w=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	From;
	b=p6nybMRVD+vEWqDxJwhxZb+mVALDhuy7YiXOQqdWDB3AGj/AHoQr2p6ztb5SMzKSR
	0EyofHbu929XSs6teMOdM3l1/O3Cn52/vK/TAN2TW0NYuEshiIA8i1zjrj6T9Q7u8S
	6uMe4iEAfnE8xZqSjlDqNh/Two9B9a9d97sMImq0=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
Date:	Wed, 15 Feb 2023 14:41:18 +0100
To:	cygwin AT cygwin DOT com
Subject:	Re: Fw: Re: Why do these mprotect always fail?
Message-ID:	<Y+zg/ikItccIAb4z@calimero.vinschen.de>
Mail-Followup-To:	cygwin AT cygwin DOT com,
	w6b7rk5yu4mt25v3 <w6b7rk5yu4mt25v3 AT protonmail DOT com>
References:	<yxifinJpR7DQ4XDFwpYMrUknNpsg8wu5T1KYPeNIwjf3FL_lYou0whmzg-XCoFgYlcz96k0yEjkrxCOQOOTztnk_tvW7ZNi8_riHbsOn-ZU=@protonmail.com>
	<ruVqVpKyYTyh3m-4mzaAg2pyhJAqlamcbUYKB8ghh_LwAKIqpabv0LNqlt8_Owfzx0Hc6c1C6nJE4Czf4hod2ukAWe3b6p_WAaaGLPk7CI8=@protonmail.com>
	<Y+y0zRQWVRWBkhCX AT calimero DOT vinschen DOT de>
	<TlepM9ESIu1ZpPCpz1vzmSoBKsKnuUABID2BREun8gb9tEPApKByf5s-_DHR9C6h48OdPFnU5uZ0Xc4JTTd-gtPH2RqhOHgOiSh-spI9K88=@protonmail.com>
	<Y+zMcAP/eIZ1DTi8 AT calimero DOT vinschen DOT de>
	<0Qjpbo0t_1WTd9--kVw5gLR1PdJzG7myKYzhxdzDIqnWYwLnywFCtSbekykskWViaSJM_bcLQBEFT_wg4-IApgEYrX5bHFIZH7Ro40oDYGs=@protonmail.com>
MIME-Version:	1.0
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
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	cygwin AT cygwin DOT com
Cc:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>,
	w6b7rk5yu4mt25v3 <w6b7rk5yu4mt25v3 AT protonmail DOT com>
Errors-To:	cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

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

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -