From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by sourceware.org (Postfix) with ESMTPS id 7C9D63858C33 for ; Wed, 19 Jul 2023 15:28:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7C9D63858C33 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-ot1-x32e.google.com with SMTP id 46e09a7af769-6b9cf17f69cso619606a34.0 for ; Wed, 19 Jul 2023 08:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1689780519; x=1690385319; 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=PNKvskG8ZxEPSEnZNgKvqv0g1bZnQqguRKT9avN7ne8=; b=NpjUmf/d7270jGbUNTnH3w/84V98paL+RWMNlm0FELSK0N3O8aYtpwYjHpsbOosAVc ZwT/F+epzoqVy8nN95NPjtFkto2Zz7sh9LZxN90yC7FFho0dhfmu8sP8thS87o9XOD2F +habirKh8FGQIpsmGwTJ18YoTbtCsXz5+BupLfVD42vFy2sa3zqt/EySTMyhYOaZQtc3 pJbeZaCv7QajJX0EVflbrZKEhYR9aO6TB806hGUb9qLRiwCQoWR45h6W2ViRGI2/VrR4 x5qMn++QHiywHv46TdJq+qs8r7fulaLZBhLPJUSvRtJ7jL8MbGTWHY87cq2W+vrA9mn8 2zAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689780519; x=1690385319; 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=PNKvskG8ZxEPSEnZNgKvqv0g1bZnQqguRKT9avN7ne8=; b=f2IQkyNLfFPtqZXuP9ZC5blzrH/eF8nFyFZXugKl6JEz8i7QdzZCWqdBl9BLzSSDmr dN6E5F/h4l+b2OLw8QG6Rm5Uxrjt15jPz1cel8w8tLHEaHfrKP/ljmMXEKTzJbQEV4aX RNaiPUyioTe8yzRkU31AvuErh0S0+dzbEF+tFX9c0Qin/xmd8yFY9v055DCkgy7J+yGa GHQRa56zrrxDLeA8inYdkHVrsTAKKAdkDlj1/mWccAbIYdV1tW5CbC3Pk1SgYXIi26li QzaEIZTEVRGZAeu6Gqo/iAeR8WDsXXx2vuhYVSbSRLlsUIIjx5A+SE1kra5lgKujeGx/ xePg== X-Gm-Message-State: ABy/qLYpvkUZ6Xapuq+9qioSzq4LEZknosWbaYd1/TrIrWFvr7VcgSVk Sghay0t7GLnlZGAUlDYZw06aygxUxPhmcrS9c34o1w== X-Google-Smtp-Source: APBJJlFs4Nod+FAF8kvPOYYY3nRJBt7kUvZLuE6EaVBuwQDn2dMYEJNlNN9cRNNCiFgeiCB4ISx87g== X-Received: by 2002:a05:6830:44a1:b0:6b7:2ef3:37aa with SMTP id r33-20020a05683044a100b006b72ef337aamr70776otv.15.1689780519626; Wed, 19 Jul 2023 08:28:39 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:d4d2:214b:b6d7:d18d:b186? ([2804:1b3:a7c0:d4d2:214b:b6d7:d18d:b186]) by smtp.gmail.com with ESMTPSA id u21-20020a4a9e95000000b00563155bd360sm1982707ook.17.2023.07.19.08.28.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jul 2023 08:28:38 -0700 (PDT) Message-ID: <559fa9e0-8245-5eed-0788-39dee9110cb9@linaro.org> Date: Wed, 19 Jul 2023 12:28:35 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: gcc-14 Wflex-array-member-not-at-end may-be-ub in struct pthread Content-Language: en-US To: Mathieu Desnoyers , =?UTF-8?Q?Cristian_Rodr=c3=adguez?= , Paul Eggert , Carlos O'Donell , "Andreas K. Huettel" Cc: Adhemerval Zanella via Libc-alpha References: <72030a27-e222-6835-7be1-e34f07b46d0e@cs.ucla.edu> <8cbaa90f-fa6e-fd5e-3ae0-5b0bcdc8fddd@linaro.org> <7cbb7b91-dd4a-39ae-faae-b107a6b72826@efficios.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <7cbb7b91-dd4a-39ae-faae-b107a6b72826@efficios.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 19/07/23 11:55, Mathieu Desnoyers wrote: > On 7/19/23 10:22, Adhemerval Zanella Netto wrote: >> >> >> On 19/07/23 11:17, Adhemerval Zanella Netto wrote: >>> >>> >>> On 08/07/23 16:21, Cristian Rodríguez via Libc-alpha wrote: >>>> On Wed, Jul 5, 2023 at 2:13 PM Cristian Rodríguez >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Jul 5, 2023 at 11:53 AM Paul Eggert wrote: >>>>> >>>>>> On 2023-07-05 06:46, Cristian Rodríguez via Libc-alpha wrote: >>>>>>>     char end_padding[]; --> This is incorrect, since struct rseq >>>>>> contains a >>>>>>> flexible array it must be the last member.. >>>>>> >>>>>> ? struct rseq doesn't contain a flexible array on the master branch, so >>>>>> there's no error here. >>>>>> >>>>> >>>>> I may be missing something but I have struct rseq containing a final >>>>> flexible array.. >>>>> >>>>> /* >>>>>           * Flexible array member at end of structure, after last feature >>>>> field. >>>>>           */ >>>>>          char end[]; >>>>> } >>>>> >>>>> this happens because: >>>>> >>>>> #ifdef __has_include >>>>> # if __has_include ("linux/rseq.h") >>>>> #  define __GLIBC_HAVE_KERNEL_RSEQ --> that is defined >>>>> # endif >>>>> >>>>> >>>>>> Perhaps you tried to nest 'struct pthread' inside another struct? If so, >>>>>> the C standard doesn't allow that but the attached untested patch should >>>>>> be a trivial fix. >>>>>> >>>>> >>>>> Your patch does indeed silence this particular warning, thanks. >>>>> >>>> >>>> I suggest you add this patch to the release queue. because as far as I can >>>> tell, It is UB when the kernel headers are present on the system. >>> >>> The flexible array on rseq was added on linux 6.3, should we treat this as >>> release blocker? >> >> Also, glibc currently does not handle AT_RSEQ_FEATURE_SIZE/AT_RSEQ_ALIGN. Is >> this a potential issue for newer kernels? > > I would expect that if a libc expects struct rseq to be fixed-size, it should use its own copy of the kernel headers. A libc expecting the fixed-size struct rseq still works with newer kernels. Since glibc uses the user exported sys/rseq, it ends up using the kernel header if present for the 'struct rseq' definition. > > Having libc support the feature size/align AT_ queries for extensible RSEQ will become necessary as we use all the 12 bytes of padding that > were present at the end of the original struct rseq for new fields. Current we use the 'sizeof (struct rseq)' from struct pthread as the value for __rseq_size, so it seems that it should be ok regardless whether kernel header is used or not. The only issue is whether the UB of having a middle struct with flexible array might trigger any code generation issue. > > So supporting the AT_RSEQ extensible RSEQ should be done sooner than later, but I don't see it as a release blocker for libc.