mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Jiri Slaby <jirislaby@kernel.org>,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
	linux-hardening@vger.kernel.org
Subject: Re: [PATCH][next] tty: tty_buffer: Avoid hundreds of -Wflex-array-member-not-at-end warnings
Date: Wed, 5 Feb 2025 17:19:35 +1030	[thread overview]
Message-ID: <3befc536-3bf8-4a79-9815-3386912069b2@embeddedor.com> (raw)
In-Reply-To: <2025020503-unnamable-canopener-ac71@gregkh>



On 05/02/25 16:06, Greg Kroah-Hartman wrote:
> On Wed, Feb 05, 2025 at 03:51:35PM +1030, Gustavo A. R. Silva wrote:
>> -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
>> getting ready to enable it, globally.
>>
>> So, in order to avoid ending up with a flexible-array member in the
>> middle of other structs, we use the `struct_group_tagged()` helper
>> to create a new tagged `struct tty_buffer_hdr`. This structure
>> groups together all the members of the flexible `struct tty_buffer`
>> except the flexible array.
>>
>> As a result, the array is effectively separated from the rest of the
>> members without modifying the memory layout of the flexible structure.
>> We then change the type of the middle struct member currently causing
>> trouble from `struct tty_buffer` to `struct tty_buffer_hdr`.
>>
>> We also want to ensure that when new members need to be added to the
>> flexible structure, they are always included within the newly created
>> tagged struct. For this, we use `static_assert()`. This ensures that the
>> memory layout for both the flexible structure and the new tagged struct
>> is the same after any changes.
>>
>> This approach avoids having to implement `struct tty_buffer_hdr` as a
>> completely separate structure, thus preventing having to maintain two
>> independent but basically identical structures, closing the door to
>> potential bugs in the future.
> 
> Why not just have a separate structure and embed that in the places it
> is used?  No duplication should be needed or am I missing something?

The duplication of members in struct tty_buffer (all of them except the
flexible array) and the new separate struct looks like this:

diff --git a/include/linux/tty_buffer.h b/include/linux/tty_buffer.h
index 31125e3be3c5..6f47a6ea5a05 100644
--- a/include/linux/tty_buffer.h
+++ b/include/linux/tty_buffer.h
@@ -22,6 +22,19 @@ struct tty_buffer {
         u8 data[] __aligned(sizeof(unsigned long));
  };

+struct tty_buffer_hdr {
+        union {
+                struct tty_buffer *next;
+                struct llist_node free;
+        };
+        unsigned int used;
+        unsigned int size;
+        unsigned int commit;
+        unsigned int lookahead;         /* Lazy update on recv, can become less than "read" */
+        unsigned int read;
+        bool flags;
+};
+
  static inline u8 *char_buf_ptr(struct tty_buffer *b, unsigned int ofs)
  {
         return b->data + ofs;
@@ -37,7 +50,7 @@ struct tty_bufhead {
         struct work_struct work;
         struct mutex       lock;
         atomic_t           priority;
-       struct tty_buffer sentinel;
+       struct tty_buffer_hdr sentinel;
         struct llist_head free;         /* Free queue head */
         atomic_t           mem_used;    /* In-use buffers excluding free list */
         int                mem_limit;

 > Did you change anything in this structure?  By reformatting it, it's
 > hard to tell what happened, so please don't do that :(

Yes - the above change is the reason why I reformatted the whole thing.

> 
> I don't mind that, it would make this all much simpler and more obvious
> over time, and the tty layer needs all the "simplification" it can get
> :)

If the above changes are better for you then I'll send a new patch. :)

Thanks
-Gustavo

  parent reply	other threads:[~2025-02-05  6:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-05  5:21 Gustavo A. R. Silva
2025-02-05  5:33 ` Greg Kroah-Hartman
2025-02-05  5:36 ` Greg Kroah-Hartman
2025-02-05  6:45   ` Jiri Slaby
2025-02-05  6:49   ` Gustavo A. R. Silva [this message]
2025-02-05  6:59     ` Jiri Slaby
2025-02-05  8:03       ` Gustavo A. R. Silva
2025-02-05  8:16         ` Greg Kroah-Hartman
2025-02-05  8:25           ` Gustavo A. R. Silva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3befc536-3bf8-4a79-9815-3386912069b2@embeddedor.com \
    --to=gustavo@embeddedor.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gustavoars@kernel.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®