From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) by sourceware.org (Postfix) with ESMTPS id 3547D3853828 for ; Tue, 8 Jun 2021 17:19:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3547D3853828 Received: by mail-qv1-xf33.google.com with SMTP id u13so11199461qvt.7 for ; Tue, 08 Jun 2021 10:19:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kTbzj6KEZXG6SMLQ1a50UFPZlG4vQt1S5NwDpwwF8RA=; b=DQshHQw8SCSfOSW3I/Zno1oI8s5U/64a367xw/CYz92zsB0Gv/Zi4KeTe866/TAZN1 KP0jDa+Nuw+cbJqb+dptgkEMyYLxbFw4YQnMsicVPuh6zVTyqYhr3uH3H6MdS4BM6o3Y NFOPKXWqxOVxVz28nehlowx17m4CjTB8tN84whw5NNRrhozZpo1zDVTuD1BOimFm9KgA 8cWQ8bk/0W2pCrvBoSsKdaKMYO1BiXamoDWJqwdh2M2TqMki5QhDnwIj6Wb2GqobFe1s KZ2ZAKj1016uyiK6LuovdN7/EuY4QXD/WKAFjvTFaOeWKVIVB17q4fOQzhR+uLUR2FuE r1Bw== X-Gm-Message-State: AOAM531UXQMdEr3OArWwqZjuMBxtR5P7aiUGd0CfemDEYBRD1OiHYMEG n+wvUcTB/hyqQr8oRnbDxNiVyik8PVMxjA== X-Google-Smtp-Source: ABdhPJyUoATKxqX88/Sxr6ALhYPzvO5fQ0SSglmHVgkMc2Rhv0vQmamanOorbWelPfrHLU7dHSz1PA== X-Received: by 2002:a05:6214:1021:: with SMTP id k1mr1205159qvr.4.1623172770719; Tue, 08 Jun 2021 10:19:30 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id p63sm12117822qkf.31.2021.06.08.10.19.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Jun 2021 10:19:30 -0700 (PDT) From: Adhemerval Zanella Subject: Re: inode-based dlopen caching To: Florian Weimer , Libc-help References: <87zgw09tww.fsf@oldenburg.str.redhat.com> Message-ID: <0242da65-0563-d03d-2ba7-5318c2a6c010@linaro.org> Date: Tue, 8 Jun 2021 14:19:28 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87zgw09tww.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 17:19:32 -0000 On 08/06/2021 13:56, Florian Weimer via Libc-help wrote: > * Soni L. via Libc-help: > >> Currently dlopen caching is based on filenames, it'd be nice if it was >> based on inodes to support better "re"loading (aka loading a new module >> with the same name because unloading modules with threads is never a >> good idea). This is good for stuff that deals with plugins. > > It's an interesting idea. We'd probably also want a flag that hides the > symbols from general binding and makes them available for direct dlsym > lookups using the handle returned by dlopen (otherwise the old > definitions stick around). > > The tricky question is what to do about dependencies. A behavioral > change for just one level is not too hard, but everything goes further > is difficult. > > Vivek Das Mohapatra's RTLD_SHARED patches may help with isolating > dependencies. The RTLD_SHARED with the -Wl,-z,unique might help with the dependency, but it would require the caller to proper setup the linker flag on the specific shared libraries. But my main reservation with this is the idea of reload the new module is, although the symbol resolution is a different namespace, it still share the same process resources. It would require a lot of careful code within the library so it can run with multiple instances, we see the potential issues with our static dlopen support.