From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpout.efficios.com (unknown [IPv6:2607:5300:203:b2ee::31e5]) by sourceware.org (Postfix) with ESMTPS id A07A33858C33 for ; Wed, 19 Jul 2023 14:54:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A07A33858C33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=efficios.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1689778496; bh=SSLzBlN41FsVi0+xAN0ZoDf+Np+Cw+UgqdYCn1IDsLI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=OIZYXfCvmKYEpA5AXw2H9sSgFxDbA/f3+qDqkoW24Oc1ymaIpeviv4jyeAXjhKdCZ VnARO094hu3yAKdHDYCvEP4Da8el4g0g4zkbYuyMYCtuJKusMXMD7VeOpln8kE2XbP QsyzSzZInDBYvDCgOoUM+c0wnsbMQcOEmvai2MKVJ6U5WttfHcf7YqGbXJs+CNjDNu Zv0GI2q92JD5pLbyzki80gLEujygYFGuCQwWpkDw08vd/V7OskEmUGUMk14f3sA4RL 9T6KF29JQ8VBm9JXzPucjn//tpLfgHIV0G2Hrjakp4e1pOhA3BiyLAntnvFTtYW/2x 8JOnVF4SaiDpw== Received: from [172.16.0.134] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4R5f4J1Wk5z1J0t; Wed, 19 Jul 2023 10:54:56 -0400 (EDT) Message-ID: <7cbb7b91-dd4a-39ae-faae-b107a6b72826@efficios.com> Date: Wed, 19 Jul 2023 10:55:38 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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: Adhemerval Zanella Netto , =?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> From: Mathieu Desnoyers In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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 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. 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. 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. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com