From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) by sourceware.org (Postfix) with ESMTPS id C29753858D20 for ; Thu, 9 Mar 2023 17:43:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C29753858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oo1-xc2f.google.com with SMTP id p8-20020a4a3c48000000b0052527a9d5f0so403363oof.1 for ; Thu, 09 Mar 2023 09:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678383791; h=content-transfer-encoding:in-reply-to:organization:references:cc:to :from:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=3FQCfYDexsyHXZ0Gxu1lJmEqeOTLGpaQIVJyBLa+62s=; b=ERftRwlklk+ZJUKlU4LagXLlFj1RQa+K7sezEP0tF4OzwsUsQTDMX5HgaG3daDPkQd 6jbV6R67wV8Wh/j4HZZCLtHpiTiDqHDCkgnLacwTdyF+eSZ94F0en1l2BSb+QbzHj0/h C5q7IUqan4a+FdrrL0VsiXQiMd05M1HakPvto/1zGt5AHm18qyvDb55jACxjWEEeQvn8 KbUrH5onJyYudoCrYCbNHPU7uHNnjiRRGALDUBXOoLn47ZHL0u3jtqBuvoAdQOhTe7cF Jz46X6pgk8mZZwmHjTcBMKxTFyg5I68wfl8KsANuCjqzbMHysxP2bW7faVL5MfouadYW 8xTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678383791; h=content-transfer-encoding:in-reply-to:organization:references:cc:to :from:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3FQCfYDexsyHXZ0Gxu1lJmEqeOTLGpaQIVJyBLa+62s=; b=pXzezZiotZXAx39b/WzYHj0e0nZWM6r55jp2VLzMw0iKPGY0ZB9RJPQCznFKXG2DEI 7RrGG4XA59TO7xL/Q1cbvz4GNUDDm7nO1yX4X1pc/8X6509P4ajrLiSmmjbFB6ZmTyQn qoKTCvyW43qvVhJhZBJP800iFnDcnhewcO0BgEyHA1PhqRntu8UMtuaeUJ1/UYZijcXl aMfRcVhJWcfvULLg9nNgn3XcauvtxAke+i0+09ZPTaSyQkjbY8UUa9fHZRVUcwrAw10Z riRWigzxVW5u7lyPn6UmQg1wp+kuie9b5sF7GnBVvDotdh247/fvwGcXJVNTlqiDohmb zwcA== X-Gm-Message-State: AO0yUKVp9NJ4aKIwKg6YKzd9r+HEaUDQP2iugox6XVRjFHT57UtLT1wh LaOyUL2WfOmWYYGt+1JU0QDnuWVG64mDI9qN6WX0sA== X-Google-Smtp-Source: AK7set+0g2/d7uLF+7T35W8JLqN+OopVyD7AZ1Atk+pjQyol/ci6NfLjQEahK3ls7BHq0M3vrZx+Ng== X-Received: by 2002:a4a:d014:0:b0:525:48a9:9ba with SMTP id h20-20020a4ad014000000b0052548a909bamr8518796oor.0.1678383791034; Thu, 09 Mar 2023 09:43:11 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c0:544b:655d:5559:758d:90f7? ([2804:1b3:a7c0:544b:655d:5559:758d:90f7]) by smtp.gmail.com with ESMTPSA id 129-20020a4a1487000000b0052569fb1cfesm7524096ood.28.2023.03.09.09.43.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Mar 2023 09:43:10 -0800 (PST) Message-ID: <676ee95e-9981-a0cd-36b3-231b64b82673@linaro.org> Date: Thu, 9 Mar 2023 14:43:08 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] RFC: Provide a function to reset IFUNC PLTs Content-Language: en-US From: Adhemerval Zanella Netto To: Jan Kratochvil Cc: Florian Weimer , libc-alpha@sourceware.org, Anton Kozlov References: <87v8jdq7ht.fsf@oldenburg.str.redhat.com> <2659aadc-6518-cc0e-d103-84eafcbdc3f9@linaro.org> Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 09/03/23 12:47, Adhemerval Zanella Netto wrote: > > > On 09/03/23 08:32, Jan Kratochvil wrote: >> On Wed, 08 Mar 2023 21:04:59 +0800, Adhemerval Zanella Netto wrote: >>> Yes, without a stop-the-world scheme where a helper thread sets PR_GET_DUMPABLE >>> and PTRACE_ATTACH the process can not really be sure that any new thread will not >>> be created between the time you enumerate the process threads and call the 'freeze' >>> function. >> >> That "Freezer" class does solve the race of new threads. I also do not see >> a need for ptrace there, it is self-snapshotting/restoring. >> https://github.com/openjdk/crac/pull/41/files#diff-aeec57d804d56002f26a85359fc4ac8b48cfc249d57c656a30a63fc6bf3457adR6029 > > I am not sure how the kernel would enumerate new tasks that are created > while iterating over /proc/self/task. On closefrom Linux fallback we have > a similar problem, where the code iterates over /proc/self/fd, and everytime > it closes a file descriptor it lseeks back to beginning. It works because > eventually there will be no more entries on /proc/self/fd, so either you > will need to certify that kernel adds new tasks at the end of the getdents > call (used by readdir, or lseek and keep track of all tasks already signaled. And the 'handler' signal handler has some potential shortcomings as well: * backtrace is not async-signal-safe: glibc implementation on first call issues dlopen, which calls malloc; and libgcc_eh.so *might* also calls malloc. * pthread calls are not async-signal-safe either. * it only handles libc.so, other libraries that uses ifunc for function selection also fails. * the syscall heuristics do not handle partial results (for instance if write syscall returns do EINTR). So this code has the potential of deadlock, specially if you have another thread issuing malloc.