From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 3D055398B879 for ; Thu, 5 Aug 2021 08:27:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3D055398B879 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-433-njwOVjGtPM2GFOaySfmEYw-1; Thu, 05 Aug 2021 04:27:20 -0400 X-MC-Unique: njwOVjGtPM2GFOaySfmEYw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C1D6687D541 for ; Thu, 5 Aug 2021 08:27:19 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.123]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C515F1057F64; Thu, 5 Aug 2021 08:27:16 +0000 (UTC) From: Florian Weimer To: Andrew Haley via Libffi-discuss Subject: Re: is fork() supported? References: Date: Thu, 05 Aug 2021 10:27:15 +0200 In-Reply-To: (Andrew Haley via Libffi-discuss's message of "Thu, 5 Aug 2021 09:17:54 +0100") Message-ID: <87tuk447q4.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 08:27:23 -0000 * Andrew Haley via Libffi-discuss: > On 8/4/21 9:00 PM, DJ Delorie via Libffi-discuss wrote: >> I don't mean fork/exec (duh) but a fork() and keep going... >> >> Consider a case where a process is using a file-backed mapping for >> closures; a fork() doesn't isolate that backing between parent/child >> so there's a chance (for example) the parent could deallocate a >> closure that the child needs, etc... >> >> I see four options... >> >> 1. Not supported. Sorry. >> >> 2. Supported only if you have fork-able closure backings (mmap or >> maybe ktmpfile, but not file-backed) but this means documenting >> that (at least) selinux settings might affect this. Caveat >> Programmer. >> >> 3. Some API that says "I need this" so it can fail in a more useful >> way than "segfault". >> >> 4. Fully supported, and we have some work to do to handle fork events. > > The bug that will never die. > > https://bugzilla.redhat.com/show_bug.cgi?id=1249685 > https://bugzilla.redhat.com/show_bug.cgi?id=531233 > https://bugzilla.redhat.com/show_bug.cgi?id=772657 Well, there are two ways to fix it: Avoid the need for alias mappings by switching to static trampolines, or create new alias mappings upon fork. (A third option would be kernel support for private alias mappings. A fourth, get some form of explicit JIT support for SELinux.) Thanks, Florian