From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by sourceware.org (Postfix) with ESMTPS id 6F4FA3858D3C for ; Thu, 26 Aug 2021 17:45:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6F4FA3858D3C Received: by mail-qk1-x733.google.com with SMTP id f22so4295007qkm.5 for ; Thu, 26 Aug 2021 10:45:50 -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:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VRyYw69dIlM63x/BRyG/u713gWt4md1MCJrmrwMNt18=; b=jwsQS3BycEyHaTdsqh2prAGw0/XVZ+IvAdJy4LMKlTt+YNqfUm8mMaC3xNc4tJwvFc wz3St39kf0i7z0d5miXowA9CM///EVkPTTmlrICfk/A5SotJp7Rclg+GepYoeYJytKBF qxrXFnca1nvJXazUDr6sl+DlN3KKYz3qTGYsdzjVJtjBw9RVdmlfYFjjNr7ZiBsKFHbd Ypq2LPupFwAVx2Bf65MSZ01srvLbta92f63JghnjqOSwQ7nPqM6T5zfpZ3UpTLAXdseE 5B2MMEWrWVnl8WW1CofBPkKR8Vf06vMhmXYZPOjU12jtGgd2yd5Qk20TvoF4aC5gn9Dt no2g== X-Gm-Message-State: AOAM530PcvFgHdTe3IQ69qSV2okMSst6ceGXdssCzFpHxF2z1lYNU4wH KGDm9kB42VgVBOML3EpNECYZ7d5rPyPiJA== X-Google-Smtp-Source: ABdhPJwhcyjlIn8AarxEtZJiXrnCbda4mX5zV8soCsgqe4CylW8sJZKwQAqRQzug6HYaCICu6dWscg== X-Received: by 2002:a05:620a:1485:: with SMTP id w5mr5162828qkj.448.1629999949906; Thu, 26 Aug 2021 10:45:49 -0700 (PDT) Received: from ?IPv6:2804:431:c7ca:1a68:4e82:9e7c:b7e4:7f3? ([2804:431:c7ca:1a68:4e82:9e7c:b7e4:7f3]) by smtp.gmail.com with ESMTPSA id y19sm2172274qtv.21.2021.08.26.10.45.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Aug 2021 10:45:49 -0700 (PDT) Subject: Re: [PATCH v2 15/19] nptl: Use tidlock when accessing TID on pthread_getname_np To: Florian Weimer Cc: libc-alpha@sourceware.org References: <20210823195047.543237-1-adhemerval.zanella@linaro.org> <20210823195047.543237-16-adhemerval.zanella@linaro.org> <87ilzs5l0a.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: Date: Thu, 26 Aug 2021 14:45:48 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87ilzs5l0a.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.7 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Thu, 26 Aug 2021 17:46:00 -0000 On 26/08/2021 11:38, Florian Weimer wrote: > * Adhemerval Zanella: > >> + /* Block all signal, since the lock is recursive and used on pthread_cancel >> + (which should be async-signal-safe). */ >> + sigset_t oldmask; >> + __libc_signal_block_all (&oldmask); >> + lll_lock (pd->tidlock, LLL_PRIVATE); >> >> - int fd = __open64_nocancel (fname, O_RDONLY); >> - if (fd == -1) >> - return errno; >> + char fname[sizeof ("/proc/self/task//comm" ) + INT_BUFSIZE_BOUND (pid_t)]; >> + __snprintf (fname, sizeof (fname), "/proc/self/task/%d/comm", pd->tid); >> >> int res = 0; >> - ssize_t n = TEMP_FAILURE_RETRY (__read_nocancel (fd, buf, len)); >> - if (n < 0) >> - res = errno; >> - else >> + int fd = __open64_nocancel (fname, O_RDONLY); >> + if (fd != -1) >> { >> - if (buf[n - 1] == '\n') >> - buf[n - 1] = '\0'; >> - else if (n == len) >> - res = ERANGE; >> + ssize_t n = TEMP_FAILURE_RETRY (__read_nocancel (fd, buf, len)); >> + if (n > 0) >> + { >> + if (buf[n - 1] == '\n') >> + buf[n - 1] = '\0'; >> + else if (n == len) >> + res = ERANGE; >> + else >> + buf[n] = '\0'; >> + } >> else >> - buf[n] = '\0'; >> + res = errno; >> + >> + __close_nocancel_nostatus (fd); >> } >> + else >> + res = errno; > > ENOENT for exited threads is inconsistent with ESRCH (or 0) in other > cases. Right, I think we will need to map ENOENT to ESRCH. But I also think this is another fix. > > I wonder if we should cache the thread name in the TCB. That would be > nice for debugging coredumps, too. This does not make sense, although it would require some memory allocation.