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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id DA6F61F9E0 for ; Wed, 22 Apr 2020 16:38:14 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DCD7C394D81A; Wed, 22 Apr 2020 16:38:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DCD7C394D81A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1587573493; bh=bc9u0h7WIJy7ib3NCZimk75bs4AvOVV9paDK6c1a6rw=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=UpwSZbV9k/fYehpUIuU4iyMZOwDBH/lxOy7RxN/WkKbtwNz0EMZe0/R4xhQDEQJLX djvQDFMr6+o+z2Y9R2/USGDDlh13mW+gEACfBBOQehJY0byPGkZaLyt7jv8oDUhXnT hg4mj/8MDBSmRQecDTiRXMi3Asaz6hfnHuOR3N0c= Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id B775D394D804 for ; Wed, 22 Apr 2020 16:38:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B775D394D804 Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-332-wLxzj0iiOcGK1xLMd1xagA-1; Wed, 22 Apr 2020 12:38:10 -0400 X-MC-Unique: wLxzj0iiOcGK1xLMd1xagA-1 Received: by mail-qv1-f72.google.com with SMTP id r10so2737657qvw.23 for ; Wed, 22 Apr 2020 09:38:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=bc9u0h7WIJy7ib3NCZimk75bs4AvOVV9paDK6c1a6rw=; b=uXEzrTQxfwwzrrueiMT3qxPO/SkOlQ+yA6y4kBvRhaTY/zVixOtTb2GKaWyVfzIn/x h1QpFpW9uWKFX8Oz4FZYpnlArMyjyOPUHKq2tT8/vCjd+CBnk0rs2WIXoBDn5UJwwVYV /37lw+M5nZ2NTCeVeYwLh4HBaNQw9cmTiyFNeBYSVZoupQhqusuBGlyjrpC0+sfTPY1C cvqA4POus37f+uvZugEWSrYLSid3VDZ5XelXZqgm8L+33BuwzohtmbFRDxooYjE7qmpb aJbAm4k57x/mF/30E8JB3S5A3vySc+ex3z3gWPoSdOU8GNkfPi5Lv+KUBWaC1DAUfebm zW5Q== X-Gm-Message-State: AGi0Puaq1zL8UHVn1p60HwHPslj7BNidbaDNNYk2S1ST/nf3y1GMRIua tDHUsvZIZvX2GWcLHmQ0MThqfQ4VEWrmnssA+W5bVOmdn1GnPxQw2i2IqwXNwIFRTE64eXZ4OAb 1069eTB0X9uVc2+EBtZIK X-Received: by 2002:ac8:bca:: with SMTP id p10mr25529974qti.243.1587573489350; Wed, 22 Apr 2020 09:38:09 -0700 (PDT) X-Google-Smtp-Source: APiQypLGCalWfenQjvCP2lAi84SCL4gbN0g6ZqN0Gs4A0QGP/vtxcdG1kwpPn0qotImuVmBqvAiGTQ== X-Received: by 2002:ac8:bca:: with SMTP id p10mr25529948qti.243.1587573489077; Wed, 22 Apr 2020 09:38:09 -0700 (PDT) Received: from [192.168.1.4] (198-84-170-103.cpe.teksavvy.com. [198.84.170.103]) by smtp.gmail.com with ESMTPSA id j2sm4178776qth.57.2020.04.22.09.38.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Apr 2020 09:38:08 -0700 (PDT) Subject: Re: [RFC PATCH glibc 3/8] nptl: Start new threads with all signals blocked [BZ #25098] To: Christian Brauner , Mathieu Desnoyers References: <20200323131607.15185-1-mathieu.desnoyers@efficios.com> <20200323131607.15185-4-mathieu.desnoyers@efficios.com> <20200323153156.hpdjqghjscivggjf@wittgenstein> <1742466479.7642.1584982932053.JavaMail.zimbra@efficios.com> <20200323170503.dkaad3zmwe5owc4p@wittgenstein> Organization: Red Hat Message-ID: Date: Wed, 22 Apr 2020 12:38:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200323170503.dkaad3zmwe5owc4p@wittgenstein> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Carlos O'Donell via Libc-alpha Reply-To: Carlos O'Donell Cc: libc-alpha , Joseph Myers Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 3/23/20 1:05 PM, Christian Brauner wrote: > On Mon, Mar 23, 2020 at 01:02:12PM -0400, Mathieu Desnoyers via Libc-alpha wrote: >> ----- On Mar 23, 2020, at 11:31 AM, Christian Brauner christian.brauner@ubuntu.com wrote: >> >>> On Mon, Mar 23, 2020 at 09:16:02AM -0400, Mathieu Desnoyers via Libc-alpha >>> wrote: >>>> From: Florian Weimer >>>> >>>> New threads inherit the signal mask from the current thread. This >>>> means that signal handlers can run on the newly created thread >>>> immediately after the kernel has created the userspace thread, even >>>> before glibc has initialized the TCB. Consequently, new threads can >>>> observe uninitialized ctype data, among other things. >>>> >>>> To address this, block all signals before starting the thread, and >>>> pass the original signal mask to the start routine wrapper. On the >>>> new thread, first perform all thread initialization, and then unblock >>>> signals. >>>> >>>> The cost of doing this is two rt_sigprocmask system calls on the old >>>> thread, and one rt_sigprocmask system call on the new thread. (If >>>> there was a way to clone a new thread with a signals disabled, this >>> >>> This could be a new clone3() flag. If someone wants to send a patch I'd >>> take it. >> >> I agree that it would be a nice improvement to alleviate the overhead of >> tweaking the signal masks on thread creation. I suspect the code proposed in >> this patch is still needed, because glibc would have to support the currently >> existing kernels. The improvement you envision involves adding this new flag >> into the Linux kernel clone3 system call and then wiring up glibc support. >> >> I don't expect this should delay rseq integration into glibc ? > > Oh no, I wasn't trying to say that rseq() in glibc should be blocked on > this, not at all. I was just saying we should probably do this since > it's a valuable improvement. That's up to you to decide, and it depends on the workload. I'd be hesitant to spend a flag bit on this. To cleanup the glibc code would require you to (a) implement this in the kernel (b) have glibc move the minimum kernel line above the new kernel that has this We're talking a minor cleanup that would take 10-15 years to arrive... if ever. Moving the minimum kernel baseline has container workload impacts that are going to become real problems soon. Mathieu, Florian, and I talked about this very issue at GNU Tools Cauldron 2019 (Montreal). We agreed that even if we could fix it immediately we would still need the above implementation. IMO you are doing something wrong if this shows up in your profiling though. You should not be starting up and killing threads that fast. You should be using thread pools etc. The kernel reaping of tasks is quite slow and even in glibc we often hit EAGAIN limits on heavily loaded test boxes. The above code is required for correctness so certain state is not observable, but it need not be that fast. Someone correct me if I'm wrong though and I've missed a use case. -- Cheers, Carlos.