[PATCH 0/2] --padding option to combine with --with_flexible_array

[PATCH 0/2] --padding option to combine with --with_flexible_array

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo <acme@redhat.com>

Hi,

	This implements --padding, that combined with the already
available --with_flexible_array option may catch some questionable
structs.

	This comes from a quick discussion I had with Willy Tareau after
Gustavo's talk at this year's Kernel Recipes.

	I have this in the 'next' branch of:

https://git.kernel.org/pub/scm/devel/pahole/pahole.git

	Willy, is that what you had in mind?

Cheers,

- Arnaldo

Arnaldo Carvalho de Melo (2):
  pahole: Add --padding_ge N to show only structs with at least N bytes of padding at its end
  pahole: Add --padding N to show only structs with N bytes of padding at its end

 man-pages/pahole.1 |  8 ++++++++
 pahole.c           | 17 ++++++++++++++++-
 2 files changed, 24 insertions(+), 1 deletion(-)

-- 
2.46.0

[PATCH 1/2] pahole: Add --padding_ge N to show only structs with at least N bytes of padding at its end

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo <acme@redhat.com>

Example usage:

  $ pahole --padding_ge 4 --with_flexible_array
  <SNIP>
  struct netprio_map {
          struct callback_head       rcu;                  /*     0    16 */
          u32                        priomap_len;          /*    16     4 */
          u32                        priomap[];            /*    20     0 */

          /* size: 24, cachelines: 1, members: 3 */
          /* padding: 4 */
          /* last cacheline: 24 bytes */
  };
  <SNIP>

One can combine with -x/--exclude to remove from the output common
patterns such as 'struct trace_event_' structs:

  $ pahole --with_flexible_array --padding_ge 4 --exclude trace_event_ | grep ^struct
  struct rseq {
  struct mem_cgroup {
  struct netprio_map {
  struct qdisc_size_table {
  struct sysinfo {
  struct ethtool_rxnfc {
  struct ioam6_schema {
  struct poll_list {
  struct posix_acl {
  struct proc_dir_entry {
  struct scsi_vpd {
  struct xsk_buff_pool {
  struct ieee80211_regdomain {
  struct watch_filter {
  struct landlock_rule {
  struct ghes_vendor_record_entry {
  struct packet_fanout {
  struct name_cache_entry {
  struct workqueue_struct {
  struct svc_deferred_req {
  struct cis_cache_entry {
  struct sem_undo {
  struct sidtab_str_cache {
  struct pcpu_chunk {
  struct pericom8250 {
  struct dm_name_list {
  struct linux_dirent64 {
  struct old_linux_dirent {
  struct linux_dirent {
  $

Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 man-pages/pahole.1 |  4 ++++
 pahole.c           | 12 +++++++++++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/man-pages/pahole.1 b/man-pages/pahole.1
index 0a9d8ac49fbf94d5..840f8e13807ba1be 100644
--- a/man-pages/pahole.1
+++ b/man-pages/pahole.1
@@ -223,6 +223,10 @@ Find pointers to CLASS_NAME.
 .B \-H, \-\-holes=NR_HOLES
 Show only structs with at least NR_HOLES holes.
 
+.TP
+.B \-\-padding_ge=SIZE_PADDING
+Show only structs with at least SIZE_PADDING bytes of padding at its end.
+
 .TP
 .B \-I, \-\-show_decl_info
 Show the file and line number where the tags were defined, if available in
diff --git a/pahole.c b/pahole.c
index a33490d698ead7d5..56b0ca0c55993100 100644
--- a/pahole.c
+++ b/pahole.c
@@ -60,6 +60,7 @@ static char *decl_exclude_prefix;
 static size_t decl_exclude_prefix_len;
 
 static uint16_t nr_holes;
+static uint16_t end_padding_ge;
 static uint16_t nr_bit_holes;
 static uint16_t hole_size_ge;
 static uint8_t show_packable;
@@ -824,12 +825,13 @@ static struct class *class__filter(struct class *class, struct cu *cu,
 	 * that need finding holes, like --packable, --nr_holes, etc
 	 */
 	if (!tag__is_struct(tag))
-		return (just_structs || show_packable || nr_holes || nr_bit_holes || hole_size_ge) ? NULL : class;
+		return (just_structs || show_packable || nr_holes || nr_bit_holes || hole_size_ge || end_padding_ge) ? NULL : class;
 
 	if (tag->top_level)
 		class__find_holes(class);
 
 	if (class->nr_holes < nr_holes ||
+	    class->padding < end_padding_ge ||
 	    class->nr_bit_holes < nr_bit_holes ||
 	    (hole_size_ge != 0 && !class__has_hole_ge(class, hole_size_ge)))
 		return NULL;
@@ -1239,6 +1241,7 @@ ARGP_PROGRAM_VERSION_HOOK_DEF = dwarves_print_version;
 #define ARGP_contains_enumerator 344
 #define ARGP_reproducible_build 345
 #define ARGP_running_kernel_vmlinux 346
+#define ARG_PADDING_GE		   347
 
 /* --btf_features=feature1[,feature2,..] allows us to specify
  * a list of requested BTF features or "default" to enable all default
@@ -1494,6 +1497,12 @@ static const struct argp_option pahole__options[] = {
 		.arg  = "NR_HOLES",
 		.doc  = "show only structs with at least NR_HOLES holes",
 	},
+	{
+		.name = "padding_ge",
+		.key  = ARG_PADDING_GE,
+		.arg  = "SIZE_PADDING",
+		.doc  = "show only structs with at least SIZE_PADDING bytes padding at its end",
+	},
 	{
 		.name = "hole_size_ge",
 		.key  = 'z',
@@ -1885,6 +1894,7 @@ static error_t pahole__options_parser(int key, char *arg,
 		  class_name = arg;			break;
 	case 'F': conf_load.format_path = arg;		break;
 	case 'H': nr_holes = atoi(arg);			break;
+	case ARG_PADDING_GE: end_padding_ge = atoi(arg); break;
 	case 'I': conf.show_decl_info = 1;
 		  conf_load.extra_dbg_info = 1;		break;
 	case 'i': find_containers = 1;
-- 
2.46.0

[PATCH 2/2] pahole: Add --padding N to show only structs with N bytes of padding at its end

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo <acme@redhat.com>

Example usage:

  $ pahole --padding 4 --with_flexible_array
  <SNIP>
  struct netprio_map {
          struct callback_head       rcu;                  /*     0    16 */
          u32                        priomap_len;          /*    16     4 */
          u32                        priomap[];            /*    20     0 */

          /* size: 24, cachelines: 1, members: 3 */
          /* padding: 4 */
          /* last cacheline: 24 bytes */
  };
  <SNIP>

Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 man-pages/pahole.1 | 4 ++++
 pahole.c           | 7 ++++++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/man-pages/pahole.1 b/man-pages/pahole.1
index 840f8e13807ba1be..b3e6632bdbf6b561 100644
--- a/man-pages/pahole.1
+++ b/man-pages/pahole.1
@@ -223,6 +223,10 @@ Find pointers to CLASS_NAME.
 .B \-H, \-\-holes=NR_HOLES
 Show only structs with at least NR_HOLES holes.
 
+.TP
+.B \-\-padding=SIZE_PADDING
+Show only structs with SIZE_PADDING bytes of padding at its end.
+
 .TP
 .B \-\-padding_ge=SIZE_PADDING
 Show only structs with at least SIZE_PADDING bytes of padding at its end.
diff --git a/pahole.c b/pahole.c
index 56b0ca0c55993100..780f0c4eacfe2ee8 100644
--- a/pahole.c
+++ b/pahole.c
@@ -60,6 +60,7 @@ static char *decl_exclude_prefix;
 static size_t decl_exclude_prefix_len;
 
 static uint16_t nr_holes;
+static uint16_t end_padding;
 static uint16_t end_padding_ge;
 static uint16_t nr_bit_holes;
 static uint16_t hole_size_ge;
@@ -825,7 +826,8 @@ static struct class *class__filter(struct class *class, struct cu *cu,
 	 * that need finding holes, like --packable, --nr_holes, etc
 	 */
 	if (!tag__is_struct(tag))
-		return (just_structs || show_packable || nr_holes || nr_bit_holes || hole_size_ge || end_padding_ge) ? NULL : class;
+		return (just_structs || show_packable || nr_holes || nr_bit_holes || hole_size_ge ||
+			end_padding_ge || end_padding) ? NULL : class;
 
 	if (tag->top_level)
 		class__find_holes(class);
@@ -833,6 +835,7 @@ static struct class *class__filter(struct class *class, struct cu *cu,
 	if (class->nr_holes < nr_holes ||
 	    class->padding < end_padding_ge ||
 	    class->nr_bit_holes < nr_bit_holes ||
+	    (end_padding != 0 && class->padding != end_padding) ||
 	    (hole_size_ge != 0 && !class__has_hole_ge(class, hole_size_ge)))
 		return NULL;
 
@@ -1242,6 +1245,7 @@ ARGP_PROGRAM_VERSION_HOOK_DEF = dwarves_print_version;
 #define ARGP_reproducible_build 345
 #define ARGP_running_kernel_vmlinux 346
 #define ARG_PADDING_GE		   347
+#define ARG_PADDING		   348
 
 /* --btf_features=feature1[,feature2,..] allows us to specify
  * a list of requested BTF features or "default" to enable all default
@@ -1894,6 +1898,7 @@ static error_t pahole__options_parser(int key, char *arg,
 		  class_name = arg;			break;
 	case 'F': conf_load.format_path = arg;		break;
 	case 'H': nr_holes = atoi(arg);			break;
+	case ARG_PADDING: end_padding = atoi(arg);	break;
 	case ARG_PADDING_GE: end_padding_ge = atoi(arg); break;
 	case 'I': conf.show_decl_info = 1;
 		  conf_load.extra_dbg_info = 1;		break;
-- 
2.46.0

Re: [PATCH 0/2] --padding option to combine with --with_flexible_array

[Gustavo A. R. Silva]

On 27/09/24 20:59, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo <acme@redhat.com>
> 
> Hi,
> 
> 	This implements --padding, that combined with the already
> available --with_flexible_array option may catch some questionable
> structs.
> 
> 	This comes from a quick discussion I had with Willy Tareau after
> Gustavo's talk at this year's Kernel Recipes.

Nice. :)

I think it'd be interesting to take a look at the output of the
following command:

$ pahole --padding_ge 1 --with_flexible_array

Acked-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks!
--
Gustavo

> 
> 	I have this in the 'next' branch of:
> 
> https://git.kernel.org/pub/scm/devel/pahole/pahole.git
> 
> 	Willy, is that what you had in mind?
> 
> Cheers,
> 
> - Arnaldo
> 
> Arnaldo Carvalho de Melo (2):
>    pahole: Add --padding_ge N to show only structs with at least N bytes of padding at its end
>    pahole: Add --padding N to show only structs with N bytes of padding at its end
> 
>   man-pages/pahole.1 |  8 ++++++++
>   pahole.c           | 17 ++++++++++++++++-
>   2 files changed, 24 insertions(+), 1 deletion(-)
> 

Re: [PATCH 0/2] --padding option to combine with --with_flexible_array

[Arnaldo Carvalho de Melo]

On Fri, Sep 27, 2024 at 09:22:46PM +0200, Gustavo A. R. Silva wrote:
> On 27/09/24 20:59, Arnaldo Carvalho de Melo wrote:
> > From: Arnaldo Carvalho de Melo <acme@redhat.com>
> > 
> > Hi,
> > 
> > 	This implements --padding, that combined with the already
> > available --with_flexible_array option may catch some questionable
> > structs.
> > 
> > 	This comes from a quick discussion I had with Willy Tareau after
> > Gustavo's talk at this year's Kernel Recipes.
> 
> Nice. :)
> 
> I think it'd be interesting to take a look at the output of the
> following command:
> 
> $ pahole --padding_ge 1 --with_flexible_array

acme@x1:~$ pahole --padding_ge 1 --with_flexible_array > pahole--padding_ge_1_--with_flexible_array.`uname -r`.txt
acme@x1:~$ ls -lart pahole--padding_ge_1_--with_flexible_array.6.10.10-200.fc40.x86_64.txt 
-rw-r--r--. 1 acme acme 172848 Sep 27 16:36 pahole--padding_ge_1_--with_flexible_array.6.10.10-200.fc40.x86_64.txt
acme@x1:~$ 

It is at http://vger.kernel.org/~acme/pahole--padding_ge_1_--with_flexible_array.6.10.10-200.fc40.x86_64.txt
 
> Acked-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Thanks!

- Arnaldo

Re: [PATCH 0/2] --padding option to combine with --with_flexible_array

[Gustavo A. R. Silva]

> acme@x1:~$ pahole --padding_ge 1 --with_flexible_array > pahole--padding_ge_1_--with_flexible_array.`uname -r`.txt
> acme@x1:~$ ls -lart pahole--padding_ge_1_--with_flexible_array.6.10.10-200.fc40.x86_64.txt
> -rw-r--r--. 1 acme acme 172848 Sep 27 16:36 pahole--padding_ge_1_--with_flexible_array.6.10.10-200.fc40.x86_64.txt
> acme@x1:~$
> 
> It is at http://vger.kernel.org/~acme/pahole--padding_ge_1_--with_flexible_array.6.10.10-200.fc40.x86_64.txt

Awesome. :)

Thanks a lot!
--
Gustavo

Re: [PATCH 0/2] --padding option to combine with --with_flexible_array

[Willy Tarreau]

Hi Arnaldo!

On Fri, Sep 27, 2024 at 03:59:56PM -0300, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo <acme@redhat.com>
> 
> Hi,
> 
> 	This implements --padding, that combined with the already
> available --with_flexible_array option may catch some questionable
> structs.
> 
> 	This comes from a quick discussion I had with Willy Tareau after
> Gustavo's talk at this year's Kernel Recipes.
> 
> 	I have this in the 'next' branch of:
> 
> https://git.kernel.org/pub/scm/devel/pahole/pahole.git
> 
> 	Willy, is that what you had in mind?

Oh that was fast!

I'm looking at the output here:

   http://oldvger.kernel.org/~acme/pahole--padding_ge_1_--with_flexible_array.6.10.10-200.fc40.x86_64.txt

I'm seeing in the output above that mem_cgroup was reported due to 48
bytes padding being caused by extra alignment. I'm not sure what to
think about it to be honest, there could be pros and cons. However it's
true that if this struct is embedded inside another one, it starts to
smell nevertheless, and such a case is not much frequent so it should
be a low rate of false positives in the worst case.

The output is clearly reviewable by hand, that's really cool!

I have not checked the code yet, but based on the result that's definitely
an ack for me!

Acked-by: Willy Tarreau <w@1wt.eu>

Thank you!
Willy

Re: [PATCH 0/2] --padding option to combine with --with_flexible_array

[Willy Tarreau]

On Fri, Sep 27, 2024 at 11:15:03PM +0200, Willy Tarreau wrote:
> Hi Arnaldo!
> 
> On Fri, Sep 27, 2024 at 03:59:56PM -0300, Arnaldo Carvalho de Melo wrote:
> > From: Arnaldo Carvalho de Melo <acme@redhat.com>
> > 
> > Hi,
> > 
> > 	This implements --padding, that combined with the already
> > available --with_flexible_array option may catch some questionable
> > structs.
> > 
> > 	This comes from a quick discussion I had with Willy Tareau after
> > Gustavo's talk at this year's Kernel Recipes.
> > 
> > 	I have this in the 'next' branch of:
> > 
> > https://git.kernel.org/pub/scm/devel/pahole/pahole.git
> > 
> > 	Willy, is that what you had in mind?
> 
> Oh that was fast!
> 
> I'm looking at the output here:
> 
>    http://oldvger.kernel.org/~acme/pahole--padding_ge_1_--with_flexible_array.6.10.10-200.fc40.x86_64.txt
> 
> I'm seeing in the output above that mem_cgroup was reported due to 48
> bytes padding being caused by extra alignment. I'm not sure what to
> think about it to be honest, there could be pros and cons. However it's
> true that if this struct is embedded inside another one, it starts to
> smell nevertheless, and such a case is not much frequent so it should
> be a low rate of false positives in the worst case.
> 
> The output is clearly reviewable by hand, that's really cool!

So I tried it on haproxy. The first good news is that it didn't spot
anything, indicating that it doesn't seem to trigger false-positives
(the second good news being that I don't have to fix anything there :-)).

For example I have such a struct that contains a forced alignment hole
before the flex array and it rightfully didn't catch it:

  struct ebmb_node {
        struct eb_node             node;                 /*     0    36 */

        /* XXX 4 bytes hole, try to pack */

        union {
        } __attribute__((__aligned__(8)));               /*    40     0 */
        unsigned char              key[];                /*    40     0 */

        /* size: 40, cachelines: 1, members: 3 */
        /* sum members: 36, holes: 1, sum holes: 4 */
        /* forced alignments: 1, forced holes: 1, sum forced holes: 4 */
        /* last cacheline: 40 bytes */
  } __attribute__((__aligned__(8)));

But it correctly spots this one that we imagined during our discussion:

  struct foo {
        void *                     ptr;                  /*     0     8 */
        int                        number;               /*     8     4 */
        char                       array[];              /*    12     0 */

        /* size: 16, cachelines: 1, members: 3 */
        /* padding: 4 */
        /* last cacheline: 16 bytes */
  };

So that looks all good to me!

BTW, while building the -next branch (ubuntu 22 arm64 gcc11.4), I faced
this warning that you might be interested in, and that didn't appear in
the master branch:

  In file included from /usr/include/string.h:535,
                   from /usr/include/obstack.h:136,
                   from /home/willy/pahole/dwarves.h:13,
                   from /home/willy/pahole/btf_encoder.c:13:
  In function strncpy,
      inlined from btf_encoder__add_func_proto at /home/willy/pahole/btf_encoder.c:749:4:
  /usr/include/aarch64-linux-gnu/bits/string_fortified.h:95:10: warning: __builtin_strncpy specified bound 128 equals destination size [-Wstringop-truncation]
     95 |   return __builtin___strncpy_chk (__dest, __src, __len,
        |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     96 |                                   __glibc_objsize (__dest));
        |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~
  In function strncpy,
      inlined from btf_encoder__add_func at /home/willy/pahole/btf_encoder.c:1172:4:
  /usr/include/aarch64-linux-gnu/bits/string_fortified.h:95:10: warning: __builtin_strncpy specified bound 128 equals destination size [-Wstringop-truncation]
     95 |   return __builtin___strncpy_chk (__dest, __src, __len,
        |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     96 |                                   __glibc_objsize (__dest));
        |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~

Do not hesitate to ask me for some tests if needed. I can also bisect
if needed.

Thanks!
Willy

Re: [PATCH 0/2] --padding option to combine with --with_flexible_array

[Arnaldo Carvalho de Melo]

On Sat, Sep 28, 2024 at 06:36:38AM +0200, Willy Tarreau wrote:
> On Fri, Sep 27, 2024 at 11:15:03PM +0200, Willy Tarreau wrote:
> > Hi Arnaldo!
> > 
> > On Fri, Sep 27, 2024 at 03:59:56PM -0300, Arnaldo Carvalho de Melo wrote:
> > > From: Arnaldo Carvalho de Melo <acme@redhat.com>
> > > 
> > > Hi,
> > > 
> > > 	This implements --padding, that combined with the already
> > > available --with_flexible_array option may catch some questionable
> > > structs.
> > > 
> > > 	This comes from a quick discussion I had with Willy Tareau after
> > > Gustavo's talk at this year's Kernel Recipes.
> > > 
> > > 	I have this in the 'next' branch of:
> > > 
> > > https://git.kernel.org/pub/scm/devel/pahole/pahole.git
> > > 
> > > 	Willy, is that what you had in mind?
> > 
> > Oh that was fast!
> > 
> > I'm looking at the output here:
> > 
> >    http://oldvger.kernel.org/~acme/pahole--padding_ge_1_--with_flexible_array.6.10.10-200.fc40.x86_64.txt
> > 
> > I'm seeing in the output above that mem_cgroup was reported due to 48
> > bytes padding being caused by extra alignment. I'm not sure what to
> > think about it to be honest, there could be pros and cons. However it's
> > true that if this struct is embedded inside another one, it starts to
> > smell nevertheless, and such a case is not much frequent so it should
> > be a low rate of false positives in the worst case.

Indeed, looking for structs with a flexible array that have padding
_and_ is embedded in another one looks something we should output when
asking for --with_flexible_array and --padding.

We already have "previous struct has padding", but we only see it with
--with_flexible_array and --padding right now if the struct that has it
embedded also has a flexible array _and_ padding.

Maybe we need both --embedded_flexible_array and --embedded_padding for
ultimate flexibility?

I.e. all of --with_flexible_array, --padding, --embedded_flexible_array
and --embedded_padding have value even when asked for individually, I'd
wager.

> > The output is clearly reviewable by hand, that's really cool!
> 
> So I tried it on haproxy. The first good news is that it didn't spot
> anything, indicating that it doesn't seem to trigger false-positives
> (the second good news being that I don't have to fix anything there :-)).
> 
> For example I have such a struct that contains a forced alignment hole
> before the flex array and it rightfully didn't catch it:
> 
>   struct ebmb_node {
>         struct eb_node             node;                 /*     0    36 */
> 
>         /* XXX 4 bytes hole, try to pack */
> 
>         union {
>         } __attribute__((__aligned__(8)));               /*    40     0 */
>         unsigned char              key[];                /*    40     0 */
> 
>         /* size: 40, cachelines: 1, members: 3 */
>         /* sum members: 36, holes: 1, sum holes: 4 */
>         /* forced alignments: 1, forced holes: 1, sum forced holes: 4 */
>         /* last cacheline: 40 bytes */
>   } __attribute__((__aligned__(8)));
> 
> But it correctly spots this one that we imagined during our discussion:
> 
>   struct foo {
>         void *                     ptr;                  /*     0     8 */
>         int                        number;               /*     8     4 */
>         char                       array[];              /*    12     0 */
> 
>         /* size: 16, cachelines: 1, members: 3 */
>         /* padding: 4 */
>         /* last cacheline: 16 bytes */
>   };
> 
> So that looks all good to me!

great!
 
> BTW, while building the -next branch (ubuntu 22 arm64 gcc11.4), I faced
> this warning that you might be interested in, and that didn't appear in
> the master branch:
> 
>   In file included from /usr/include/string.h:535,
>                    from /usr/include/obstack.h:136,
>                    from /home/willy/pahole/dwarves.h:13,
>                    from /home/willy/pahole/btf_encoder.c:13:
>   In function strncpy,
>       inlined from btf_encoder__add_func_proto at /home/willy/pahole/btf_encoder.c:749:4:
>   /usr/include/aarch64-linux-gnu/bits/string_fortified.h:95:10: warning: __builtin_strncpy specified bound 128 equals destination size [-Wstringop-truncation]
>      95 |   return __builtin___strncpy_chk (__dest, __src, __len,
>         |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>      96 |                                   __glibc_objsize (__dest));
>         |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~
>   In function strncpy,
>       inlined from btf_encoder__add_func at /home/willy/pahole/btf_encoder.c:1172:4:
>   /usr/include/aarch64-linux-gnu/bits/string_fortified.h:95:10: warning: __builtin_strncpy specified bound 128 equals destination size [-Wstringop-truncation]
>      95 |   return __builtin___strncpy_chk (__dest, __src, __len,
>         |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>      96 |                                   __glibc_objsize (__dest));
>         |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~

I think Eduard Zingerman has fixed this and that patch is in a series
from Alan Maguire, I'll try and process those patches now.

> Do not hesitate to ask me for some tests if needed. I can also bisect
> if needed.

Sure