From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27034 invoked by alias); 26 Apr 2012 10:00:28 -0000 Received: (qmail 26986 invoked by uid 22791); 26 Apr 2012 10:00:27 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_BF,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Apr 2012 10:00:07 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3QA07JS016856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 26 Apr 2012 06:00:07 -0400 Received: from zebedee.pink (ovpn-113-48.phx2.redhat.com [10.3.113.48]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3QA06IS000511; Thu, 26 Apr 2012 06:00:06 -0400 Message-ID: <4F991CA5.8070503@redhat.com> Date: Thu, 26 Apr 2012 10:00:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: libffi-discuss@sourceware.org Subject: Re: libffi & fork References: <4F97BF9E.6070103@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org X-SW-Source: 2012/txt/msg00186.txt.bz2 On 04/25/2012 06:32 PM, Gaash Hazan wrote: >> There is, as far as I can see, only one way to remedy this: allow >> python to map anonymous memory with both write and execute permission. >> Then it should work fine. > > I believe memory allocation is a service provided by the OS and not by > the application or interpreter. The usual problem is a mechanism such as SELinux that is forbidding Python from mmap()ing PROT_WRITE|PROT_EXEC . If you label the executable unconfined_execmem_exec_t it may work because then libffi won't bother with all this multiple maps though a shared file descriptor business. > Python does not provide memory allocation service to libffi. In this > case libffi creates read-write-exec memory block using mmap to a tmp > file. I guess the problem is common to libff users and it is not > unique to python. It's special to Python because Python is the only common libffi client that forks and then tries to use the closures. > libffi uses mmap with MAP_SHARED at libffi:closures.c:dlmap(). What > was the reason for using MAP_SHARED in the first place? > > I think MAP_PRIVATE would create the desired behavior of copy-on-write > when forked. Would that be a proper fix? No, memory regions that are backed by a real file are always shared between processes. There is a single file descriptor that references the block of memory that holds the closures. The only way you'll get it to work is to create a new file. Andrew.