From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82000 invoked by alias); 7 Oct 2016 21:23:33 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 81412 invoked by uid 89); 7 Oct 2016 21:23:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=EXPORT, act X-HELO: mail-qk0-f174.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ku8vSuiI1TK0sptvLXAorEm/saA/X9uGimOhUZrJDoY=; b=C9HWn7m7U+yaBW943j0kyVHsXxi+AiIzpyxf46uRMSoR+dPE1yjtpql25CRqVCOS89 HAhsYuNitC84HkEEp0IsSdlkB9yXWvTHQ+PyeFxrzolO6/S8eHWJIWsmJsIDDwLWjAGm IcJlIc5OtrmcYSStwtKu11oKD22Vj/QSr7z+FKRkDnedqoj+BUjcAyNtAzIfdV51LybF cT+Lpb3wpazE5bzA9J4/9MdIsOFoJ5a90kPNc/p5iANaZCnYjW3E0s6r5IfkJLoEmZhs 774liyMecobcI66iRIjtTN+G9dGYyEOMs2J3FSD0zMSLLsrJTvk22pG3OxE9xcPneLl/ JVXQ== X-Gm-Message-State: AA6/9RnxhWhdQIxl7p337UYx/w+mlg+UopegH3exJq5/MOZ6hl7JLCmEIOlExrPO12r2d3KOz11Zgh+GNDrfeA== X-Received: by 10.55.52.1 with SMTP id b1mr13382610qka.223.1475875400955; Fri, 07 Oct 2016 14:23:20 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87y4202blm.fsf@mid.deneb.enyo.de> References: <87y4202blm.fsf@mid.deneb.enyo.de> From: =?UTF-8?B?Um9iZXJ0IMWad2nEmWNraQ==?= Date: Fri, 07 Oct 2016 21:23:00 -0000 Message-ID: Subject: Re: Caching of PID/TID after fork To: Florian Weimer Cc: GLIBC Devel , Adhemerval Zanella Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-10/txt/msg00174.txt.bz2 HI all, > The stack check seems just error-prone one and I see it might be > justifiable to remove it. I am not sure how we should act on > semantic change for Linux-only syscall, so it might require to > add compatibility symbol I would try to avoid it. I was thinking that maybe the following would work (in asm), without the need to introduce additional files / codepaths. ENTRY(clone): check_for_newsp_nonnull check_for_fn_nonnull ENTRY(__clone3): clone_logic_wo_checks END(__clone3) END(clone) EXPORT(clone) EXPORT(__clone3) But, all in all, I agree that doing it (TM) right way (with support for pthread_at_fork) might be a better choice. > > > Thefore I'd like to ask for one of the following solutions: > > > > 1. Don't cache PID/TID > > > > 2. Provide some kind of symbol, which would force for TID/PID to be > > reloaded in glibc. > > I think we need a different design. > > For example, when you clone a process, you really want that all > cryptographic random number generators are reinitialized. Making this > depend on getpid does not really work, so we need a more general > solution. Agreed. > > The other question I have is whether we talk about clone-as-fork > exclusively. Introducing a new thread into the process on which > non-free-standing code can run using clone is a different matter > altogether. To my knowledge, in the vast majority of cases (or even, in all cases), where the TID/PID caching problem surfaced, it could have been solved by fork_with_flags() indeed. Though, one useful feature which could be potentially useful for some porjects would be to create a detached process (for which the kernel doesn't send termination signal - usually SIGCHLD - to the parent process). And this cannot be solved by ORing custom flags with fork ones, because SIGCHLD is already there. But, it's just a guess. --=20 Robert =C5=9Awi=C4=99cki