From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 474CA1F461 for ; Wed, 15 May 2019 08:12:07 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; q=dns; s=default; b=bJ86f MRmdp8ILNBTOuTAnrYigJTKsTPYZrxX3V9t8r2RjnaKuTthAUQ3wzaep8PYe/vD+ zO45oq36gR2SGoj49FqUPWcYSAByHy+MQyjsBcBFxAmmKzwoK6LK85VoafyX6jXO nAKBVKrh6hFAEFVw172seko+jzwP6RuxufFPSw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; s=default; bh=+6WHqOpHC13 K6w/JlLqHKZ44FBU=; b=I/Nzq8nB3rD+/hJWGRBbf4AIcWSbbgg/JLMC4SB4xFy J2kWxPM+pxjovUVPH89srkG/5XfzBN5F+h3OYDywvbla0PydFTKBLiJuuH3n+dTH VIbMMspuu/bLEC1wAGOSQW1lsgUilsvHxlXCgOWbhXNh6fEaHClzk0QyTmG4Xjvw = Received: (qmail 7054 invoked by alias); 15 May 2019 08:12:04 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 7036 invoked by uid 89); 15 May 2019 08:12:03 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: DJ Delorie Cc: codonell@redhat.com, libc-alpha@sourceware.org Subject: Re: [V2 patch] Enhance comments in nsswitch.h References: Date: Wed, 15 May 2019 10:11:55 +0200 In-Reply-To: (DJ Delorie's message of "Wed, 15 May 2019 02:07:02 -0400") Message-ID: <874l5wyw50.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain * DJ Delorie: > Florian Weimer writes: >>> + We define several types of pointers to try help identify the data: >>> + - ptr-to-malloc'd: Pointer to data which needs freeing. >>> + - ptr-to-persistent: Pointer to persistent object. >>> + - ptr-to-unloadable: Pointer to unloadlable object. */ >> >> What is a pointer to an unloadable object? A DSO handle? Or is it a >> heap pointer that is never freed? > > The intention is, if/when we allow for nsswitch.conf to be reloaded, we > need to understand which internal data *is* reloaded, and which *isn't*. > > So ptr-to-unloadable means those malloc'd objects that can be free'd > when we reload nsswitch.conf. But that doesn't seem true for e.g. service_user objects in the current framework because threads traverse the list without locking. We cannot trivially add locking because we keep pointers service_user objects across calls to NSS module functions, which can block for a long time. Furthermore, nss_load_library writes a pointer the name from the service_user object into the persistent service_library object, and that's another obstacle to deallocation. (service_user is even part of the ABI, but I'll try to come up with a patch to change that. unscd doesn't __nss_database_lookup which exposed it.) >> Is ptr-to-persistent to a static object? > > Just to something that doesn't change once created. The problem is, if > we load a DSO and some thread is using it via nss, and we reload > nsswitch.conf, we can't unload the DSO, because it might be in use. That's true for all data structures right now. However, we shouldn't dlclose any DSOs because they might not be prepared to be unloaded. > So ptr-to-persistent means it points to something that, once created, > won't go away. Since the DSO doesn't change, any data mapping names > to DSO functions also won't need to change, etc. Okay. I think the high-level question for me is whether this can-be-deallocated property is a property of the struct member (where you documented it in the patch), or a property of the type. For example, it seems to me that all name_database_entry objects can be reloaded. Maybe there is value in keeping this simple and not share data too much? Thanks, Florian