From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id 1F3683858D37 for ; Thu, 2 Mar 2023 16:55:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1F3683858D37 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-oi1-x22b.google.com with SMTP id t22so14029251oiw.12 for ; Thu, 02 Mar 2023 08:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1677776146; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=v8iGJKjsnE+bdH+KYFT4DcA6YrRb4xX1edUoAsDxGoU=; b=NoPNkJHQmYZ2n95T4lMpDoy6zinRdxVvp5fGUoEJRI8SQHQW+A7tHOfwzq5/+WHtlI glq6JqdD64JH0pAxzGKZ6Aq6ARmaHr6REQ5MrcveismVOufc0X3CpzziFcM2hjRhnefV +F968QX2XM6oiAI9ARSEwPOLSPZ6blnYDwN6zTScPmMarbDICGwyGnV+/JyL+Z5QVrFq Q7ss8sQ/UeMiRzMKkhFg6RqFEe5lccKOUHIqyvvCkHzXdiOMxI82f9cZ/shOGEa1OIKU CYUO+dQ7CZK5/pHbtVXvdS+59XfaL2BGyARhzWu3tecs8xbvRGfi3CX+C8BH1Qm1QHgZ Rd/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677776146; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=v8iGJKjsnE+bdH+KYFT4DcA6YrRb4xX1edUoAsDxGoU=; b=Q4t1+8RV44KXoF5cfy2ErFTlI12MMoiJ6cAOL7XzAAEuL70eMBsxyy1JTRUzaYsx4h /nHTCBdYdNGMLl5Z+g4ABavRkCzV4oD7ZKrklmELwUUcqfsOf+nOMwQ42FDGnTGel2An 4kztpZnYUrD3Vx4rTZjnnmGJituD8C9tdeKFlUQTuVt2lAJgazbkEzxcmvvyOZpEgQdz 9lJvU0S3WbLAxe532A3zYCiiWUm/H9OEjHDo5ObfO6VpsD+ElWB4YVoufsVks8U2XE2p EJTcifLpqoWpcC8ZrN08po4dEROAcXBGpxyVDUUpSbDkL1YmQ5wrdkil5LgX53gyeJRP I2Ag== X-Gm-Message-State: AO0yUKUlbiVlpuACalXvEdB1RJ/P0IHdmWOkh2TXNemxGXAoYiBTaMv6 rQ9zWyEqi1K9r0D9m9CI7VFWSCCZz+pqINptkJ4= X-Google-Smtp-Source: AK7set8EQbAAAyAZ5/iOdq6+f/7/vK56bXusDqFPv/kzSeQOzPp1o+8gUHFab0RhDiG8m9wARhpaUw== X-Received: by 2002:a05:6808:d3:b0:384:2318:9c22 with SMTP id t19-20020a05680800d300b0038423189c22mr5500387oic.30.1677776146350; Thu, 02 Mar 2023 08:55:46 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c3:d849:65ac:94e7:b706:d532? ([2804:1b3:a7c3:d849:65ac:94e7:b706:d532]) by smtp.gmail.com with ESMTPSA id az2-20020a056808164200b0037d74a4b8fasm7357804oib.56.2023.03.02.08.55.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Mar 2023 08:55:45 -0800 (PST) Message-ID: <7f2c31b6-9496-1db6-8eff-19df8705e1de@linaro.org> Date: Thu, 2 Mar 2023 13:55:43 -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 v4] i386: Use pthread_barrier for synchronization on tst-bz21269 Content-Language: en-US To: DJ Delorie Cc: libc-alpha@sourceware.org References: From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 01/03/23 18:37, DJ Delorie wrote: > Adhemerval Zanella writes: >> static void * >> threadproc (void *ctx) >> { >> - while (1) >> + for (int i = 0; i < NITER; i++) >> { >> - futex ((int *) &ftx, FUTEX_WAIT, 1, NULL, NULL, 0); >> - while (atomic_load (&ftx) != 2) >> - { >> - if (atomic_load (&ftx) >= 3) >> - return NULL; >> - } >> + xpthread_barrier_wait (&barrier); >> >> /* clear LDT entry 0. */ >> const struct user_desc desc = { 0 }; >> xmodify_ldt (1, &desc, sizeof (desc)); >> >> - /* If ftx == 2, set it to zero, If ftx == 100, quit. */ >> - if (atomic_fetch_add (&ftx, -2) != 2) >> - return NULL; >> + /* Wait for 'ss' set in main thread. */ >> + xpthread_barrier_wait (&barrier); >> } >> + >> + return NULL; >> } >> >> >> @@ -180,20 +163,21 @@ do_test (void) >> - for (int i = 0; i < 5; i++) >> + for (int i = 0; i < NITER; i++) >> { >> if (sigsetjmp (jmpbuf, 1) != 0) >> continue; >> >> /* Make sure the thread is ready after the last test. */ >> - while (atomic_load (&ftx) != 0) >> - ; >> + xpthread_barrier_wait (&barrier); >> >> - struct user_desc desc = { >> + const struct user_desc desc = { >> .entry_number = 0, >> .base_addr = 0, >> .limit = 0xffff, >> @@ -207,28 +191,20 @@ do_test (void) >> >> xmodify_ldt (0x11, &desc, sizeof (desc)); >> >> - /* Arm the thread. */ >> - ftx = 1; >> - futex ((int*) &ftx, FUTEX_WAKE, 0, NULL, NULL, 0); >> + /* Wait thread clear LDT entry 0. */ >> + xpthread_barrier_wait (&barrier); >> >> asm volatile ("mov %0, %%ss" : : "r" (0x7)); >> >> - /* Fire up thread modify_ldt call. */ >> - atomic_store (&ftx, 2); >> - >> - while (atomic_load (&ftx) != 0) >> - ; >> - >> /* On success, modify_ldt will segfault us synchronously and we will >> escape via siglongjmp. */ >> support_record_failure (); >> } > > this does... > > child parent > ----- ------ > > setjmp > > barrier ------- barrier > > clear LDT set LDT <-- these happen at the "same time" Yeah, ant is is clearly wrong... > > barrier ------- barrier > > set ss > support_record_failure (which hopefully segfaults before > recording failure > > > IIRC what's supposed to happen (based on the original test) is: > > setjmp > > barrier ------- barrier > > set LDT > set ss > > -- do some syscall -- > > clear LDT -- longjmp > > > When the test fails, it does this: > setjmp > set LDT > set ss > - task switch - > segfaults > > Part of me wonders if the taken longjmp causes one of the barriers to be > skipped, putting the test out of sync. If so, we won't be able to use > barriers this way. > > Ok so I did some testing on the original test case, and it seems that > the first syscall after setting %ss causes the signal, handler, and > longjmp. Which means two things: > > 1. The test must have some sort of forced syscall (INT3) or other > stack-using operation after setting %ss, to trigger the test, and > > 2. At that point, the parent longjumps to the top of the loop > > I'm not sure how we can satisfy both of these with pthread barriers, > since the one on the parent side would fault and not sync with the child > side. > > Atomics do no syscalls so do not care if %ss is bogus. It makes sense, the problem is indeed the stack access that triggers the expected failure. > > However, I also found a bug in the original code: > > futex ((int*) &ftx, FUTEX_WAKE, 0, NULL, NULL, 0); > > Per the manual, this wakes up at most zero threads. The child thread > avoids this because ftx is never set right and it's FUTEX_WAIT always > returns with EAGAIN - except when it is right, and hangs. > > /me is still investigating... > Another possibility I was wondering was to just remove this test altogether, it is already covered by kernel testing code.