From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.devel Subject: Re: GNU Guile 3.0.9rc1 available for testing! Date: Tue, 24 Jan 2023 10:43:39 -0500 Message-ID: References: <87v8l15hb2.fsf@inria.fr> <877cxd33cz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16255"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix) Cc: To: Ludovic =?utf-8?Q?Court=C3=A8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Jan 24 16:44:22 2023 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pKLTB-00041f-Vp for guile-devel@m.gmane-mx.org; Tue, 24 Jan 2023 16:44:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pKLSi-0002gb-N7; Tue, 24 Jan 2023 10:43:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pKLSg-0002gS-J6 for guile-devel@gnu.org; Tue, 24 Jan 2023 10:43:50 -0500 Original-Received: from s1.lexort.com ([71.19.148.97]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pKLSd-0007XR-Mw; Tue, 24 Jan 2023 10:43:50 -0500 Original-Received: by s1.lexort.com (Postfix, from userid 10853) id 3089A4106C5; Tue, 24 Jan 2023 10:43:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lexort.com; s=mail; t=1674575019; bh=llnCFCGrx9JxkvVUlhtoS/DdhkJrTSf56I1LDItuPRk=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=psPBosOAKkvhC0lbFHnKXjLZt4VW+NH3OiAJucGGtsB2mT1ik/k1jxyOCtFJLCOmv 9JsW0Fz1dEvxbqww+2eWTsdNzyU9tbY+sAL+f39B1qxZ6iv/b5vKLVNeunC0QU8X20 1Oj/rq2yjb8edp1OiXTancPvtwVpD9HP7J9AzavA= OpenPGP: id=098ED60E In-Reply-To: <877cxd33cz.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Mon, 23 Jan 2023 12:19:24 +0100") Received-SPF: pass client-ip=71.19.148.97; envelope-from=gdt@lexort.com; helo=s1.lexort.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:21626 Archived-At: Ludovic Court=C3=A8s writes: > My understanding is that the expectation of being able to later mprotect > that mapping to make it writable is a valid one per POSIX. Quoth > : > > If PROT_WRITE is specified, the application shall ensure that it has > opened the mapped objects in the specified address range with write > permission, unless MAP_PRIVATE was specified in the original mapping, > regardless of whether the file descriptors used to map the objects > have since been closed. > > Here the original file descriptors are O_RDONLY, but the mapping is > MAP_PRIVATE. > > I=E2=80=99m not sure how to best address that. > > Thoughts? Thanks. Definitely, let's keep this separate from 3.0.9. It is not new and it is easy for me to keep the workaround in pkgsrc. I will consult with our POSIX lawyers and see what comes of that. If it turns out, as seems likely, that this is a NetBSD bug, it will almost certainly be fixed. Either way, it might be good to have an ifdef with the workaround, but maybe with pkgsrc and few building not from pkgsrc, especially on systems that wouldn't get the likely fix, it might be better to just not do anything. I think we should wait until we understand the POSIX issues better.