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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id E0AB13858D39 for ; Wed, 25 Aug 2021 21:17:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E0AB13858D39 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-530-U6OPxSvvOLuJjIyS3nzDBw-1; Wed, 25 Aug 2021 17:17:27 -0400 X-MC-Unique: U6OPxSvvOLuJjIyS3nzDBw-1 Received: by mail-wm1-f71.google.com with SMTP id h1-20020a05600c350100b002e751bf6733so198010wmq.8 for ; Wed, 25 Aug 2021 14:17:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3yOx2zs/YRtnXsI8GF+/aDAe2H+HxYZf+y8nZJ5T3tc=; b=GPckRPD2U0CJqNfoHXbefZKNepY3zvoutkkIigsXfFhIHY8tOssD1N2gt7rSS1yiKT iwLgvCTUbS746nXe8A31FFEuKH2hbgYbV6nAaTzeZqWiqIOCY02ERXC5/j+/Cp1OgPXc EpceaM0KDQH/21DsEBq26HV/cUASmnRCq5RzchQgV82qIjEdiYrBamTyZIFQ2L+UMXQm ff+EvqNUIFerLFoi34AeJ9NRKAttPd32rbMRA+jiOzEaZWOaf89T+ofLmTF8w/lqO1Ws Z6iKqNC2ukriggOVOH7shIvZWCL9rC1quyoeYF5NLUL9nhMHNY2tKdBlYpO+jZBYFN8i 1kmw== X-Gm-Message-State: AOAM533T+qws136o5TswT8mnIj+f+XruGcylF93fnc/lg7SLxCBm/wfL Hch3Fb2OXlqLQ2U6XYAYDV7MisPbQNEOHTD+zd6J2c8sYYILDI/ncyFIBmyMWO5d6/6g5Pa6RD0 qLCXvFWKK+CF/thkxOjalyHT9A2W0UBxSumUQFAovq8hR4ORqlNJfGhyggPdkIroUSksAdYg= X-Received: by 2002:adf:c442:: with SMTP id a2mr179681wrg.228.1629926246105; Wed, 25 Aug 2021 14:17:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxGsMd74xllRxgUnBvc+oy2jsQfWjPgbr+gl1pX+QovoAb+8UsR6Bg46eANFioGvZH/2lyuPQ== X-Received: by 2002:adf:c442:: with SMTP id a2mr179663wrg.228.1629926245838; Wed, 25 Aug 2021 14:17:25 -0700 (PDT) Received: from zarquon.pink (cpc108959-cmbg20-2-0-cust731.5-4.cable.virginm.net. [80.0.22.220]) by smtp.gmail.com with ESMTPSA id s12sm1035467wru.41.2021.08.25.14.17.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Aug 2021 14:17:25 -0700 (PDT) To: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com> Cc: libffi-discuss@sourceware.org References: <09e0d2b62f62482b2fa1c29120a43078@mail.kylheku.com> <4da1a4e5-fbac-5d5f-b5ee-abe0b252ed80@redhat.com> <8a8c093795597dcc8e71e844e235a57d@mail.kylheku.com> From: Andrew Haley Subject: Re: is fork() supported? Message-ID: Date: Wed, 25 Aug 2021 22:17:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <8a8c093795597dcc8e71e844e235a57d@mail.kylheku.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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: Wed, 25 Aug 2021 21:17:41 -0000 On 8/25/21 5:59 PM, Kaz Kylheku (libffi) wrote: > On 2021-08-25 02:27, Andrew Haley via Libffi-discuss wrote: >> Note that this is *per thread*. other threads will simply continue to >> execute code in the JITted region. The JIT can generate code, but can >> not execute any JITted code until it calls >> pthread_jit_write_protect_np(true). Of course this requires threads to >> have differently-mapped regions. It would be very nice to have in >> Linux. It is the right way to do it. > > It's *a* way to do it, but tweaking the address space so that it looks > different in different threads seems extremely wrong and repugnant. It works a treat. > The threads of a process should live in exactly the same address space, > in every detail: every page, every protection bit. > > There should be no TLB switching/flushing when we task switch from > one thread to another in the same process. > > Of course, this is just another requirement, and no requirement > is absolutely non-negotiable otherwise otherwise we have religion > and not engineering. I tend to treat sentences with a "should" but no "because" as ill-formed. Only the pope gets to talk like that! ;-) Why do you care anyway? It's not as if such things will be at all common. It'll only happen if a thread's time slice expires while generating code. > However, this is a pretty firm, fundamental thing, I would think! > > If it was done without actually making different memory maps per > thread that would be great. > > For instance, suppose the mapping that is opened up for writing for > one thread is actually write protected to all threads. What happens > is this: > > 1. The "blessed" thread which owns the JIT mapping performs a write. > 2. This traps into the kernel. > 3. The kernel sees, aha, this is the blessed thread which is allowed > to write. > 4. The kernel emulates the write. > 5. The thread's instruction pointer and other machine state is fixed > up to look like it had done the write. > 6. The thread is restarted. >From userspace's point of view, that looks exactly the same, but much slower. Seems to me that it's going to be more costly than an occasional TLB flush; and if you have more processes than processors you're doing that anyway. > If the thread is not the blessed one, a fatal signal is generated, > as usual. > > One the JITted code is installed, the blessedness goes away; all > threads bomb if they write access it. > > Prior art for this, is obviously, things like simulating misaligned > memory accesses on machines that trap on misalignment. > > The downside is that it's slow for writing a large amount of JIT > material. Though installation of JIT material is amortized over the > cost of compiling it in the first place, that may still be > unacceptable overhead. (Also, it's not always amortized. Some > ahead-of-time compiling situations would also use this mechanism; > JIT is just a convenient acronym. Not all code loading is done by > mapping directly into memory. In some languages, an code object > might be read containing the executable code as a blob literal, > which is then installed as if it came from JIT). > > Really, you need a dedicated write-like syscall for this, which the > blessed thread can use to specify the bytes to be written to the > JIT memory. That is similar to the solution involving writes to > a file, except there is no file. > > In Linux, a possible place to dump this this might be oh, let's see, > prctl? > > prctl(PR_WRITE_JIT, (long) dst, (long) src, (long) size); > > [dst, dst + size) must be a MAP_JIT mapping indicating the > calling thread as being blessed, otherwise it fails. Hmm, that might work, but would be a pain. In Java we copy code around and then fix up the relocs at the destination site. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671