[PATCH] Bluetooth: btusb: Use DECLARE_FLEX_ARRAY() for memdump segment data

[PATCH] Bluetooth: btusb: Use DECLARE_FLEX_ARRAY() for memdump segment data

[Hex Lindqvist]

struct qhci_vse_memdump declares segdata as a zero-length array in a
union. Zero-length arrays are deprecated [1], so use DECLARE_FLEX_ARRAY()
instead.

No functional change: segdata is only used with offsetof(). With debug
info stripped, btusb.o is byte-for-byte identical before and after,
built with GCC 16 and Clang 21 on x86_64 and GCC 16 on arm64, with
UBSAN_BOUNDS and FORTIFY_SOURCE enabled.

An AI assistant helped find and check this change and drafted this
message.

Link: https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays [1]
Signed-off-by: Hex Lindqvist <hex@freenixos.com>
---
 drivers/bluetooth/btusb_qcom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btusb_qcom.c b/drivers/bluetooth/btusb_qcom.c
index cc4cfcde2afa..97be9078e045 100644
--- a/drivers/bluetooth/btusb_qcom.c
+++ b/drivers/bluetooth/btusb_qcom.c
@@ -533,7 +533,7 @@ struct qhci_vse_memdump {
 	__le16 seqno;
 	u8     subsys;
 	union {
-		u8 segdata[0];
+		DECLARE_FLEX_ARRAY(u8, segdata);
 		struct {
 			__le32 dump_size;
 			u8 first_segdata[];

base-commit: ebdfe8561b5496b7eafedccd13a000a7261bc52b
-- 
2.56.0

Re: [PATCH] Bluetooth: btusb: Use DECLARE_FLEX_ARRAY() for memdump segment data

[Paul Menzel]

Dear Hex,


Thank you for your patch.

Am 08.11.26 um 05:20 schrieb Hex Lindqvist:
> struct qhci_vse_memdump declares segdata as a zero-length array in a
> union. Zero-length arrays are deprecated [1], so use DECLARE_FLEX_ARRAY()
> instead.
> 
> No functional change: segdata is only used with offsetof(). With debug
> info stripped, btusb.o is byte-for-byte identical before and after,
> built with GCC 16 and Clang 21 on x86_64 and GCC 16 on arm64, with
> UBSAN_BOUNDS and FORTIFY_SOURCE enabled.
> 
> An AI assistant helped find and check this change and drafted this
> message.
> 
> Link: https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays [1]
> Signed-off-by: Hex Lindqvist <hex@freenixos.com>
> ---
>   drivers/bluetooth/btusb_qcom.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/btusb_qcom.c b/drivers/bluetooth/btusb_qcom.c
> index cc4cfcde2afa..97be9078e045 100644
> --- a/drivers/bluetooth/btusb_qcom.c
> +++ b/drivers/bluetooth/btusb_qcom.c
> @@ -533,7 +533,7 @@ struct qhci_vse_memdump {
>   	__le16 seqno;
>   	u8     subsys;
>   	union {
> -		u8 segdata[0];
> +		DECLARE_FLEX_ARRAY(u8, segdata);
>   		struct {
>   			__le32 dump_size;
>   			u8 first_segdata[];

Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>


Kind regards,

Paul

Re: [PATCH] Bluetooth: btusb: Use DECLARE_FLEX_ARRAY() for memdump segment data

[Zijun Hu]

On 11/8/2026 12:20 PM, Hex Lindqvist wrote:
> struct qhci_vse_memdump declares segdata as a zero-length array in a
> union. Zero-length arrays are deprecated [1], so use DECLARE_FLEX_ARRAY()
> instead.
> 
> No functional change: segdata is only used with offsetof(). With debug
> info stripped, btusb.o is byte-for-byte identical before and after,
> built with GCC 16 and Clang 21 on x86_64 and GCC 16 on arm64, with
> UBSAN_BOUNDS and FORTIFY_SOURCE enabled.
> 
> An AI assistant helped find and check this change and drafted this
> message.
> 
> Link: https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays [1]
> Signed-off-by: Hex Lindqvist <hex@freenixos.com>
> ---
>  drivers/bluetooth/btusb_qcom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/btusb_qcom.c b/drivers/bluetooth/btusb_qcom.c
> index cc4cfcde2afa..97be9078e045 100644
> --- a/drivers/bluetooth/btusb_qcom.c
> +++ b/drivers/bluetooth/btusb_qcom.c
> @@ -533,7 +533,7 @@ struct qhci_vse_memdump {
>  	__le16 seqno;
>  	u8     subsys;
>  	union {
> -		u8 segdata[0];
> +		DECLARE_FLEX_ARRAY(u8, segdata);
>  		struct {
>  			__le32 dump_size;
>  			u8 first_segdata[];

NAK. Please keep this as-is. since:

1) segdata[0] is a familiar GNU C idiom and, since it is only used as an offsetof() anchor, is more straightforward than the
  DECLARE_FLEX_ARRAY() expansion.

2) I guess this kind of isolated cleanup may not be welcome.As noted in Documentation/process/maintainer-netdev.rst, simple cleanups outside
   the context of other work are discouraged

Re: [PATCH] Bluetooth: btusb: Use DECLARE_FLEX_ARRAY() for memdump segment data

[Luiz Augusto von Dentz]

Hi Zijun,

On Mon, Nov 9, 2026 at 8:21 AM Zijun Hu <zijun.hu@oss.qualcomm.com> wrote:
>
> On 11/8/2026 12:20 PM, Hex Lindqvist wrote:
> > struct qhci_vse_memdump declares segdata as a zero-length array in a
> > union. Zero-length arrays are deprecated [1], so use DECLARE_FLEX_ARRAY()
> > instead.
> >
> > No functional change: segdata is only used with offsetof(). With debug
> > info stripped, btusb.o is byte-for-byte identical before and after,
> > built with GCC 16 and Clang 21 on x86_64 and GCC 16 on arm64, with
> > UBSAN_BOUNDS and FORTIFY_SOURCE enabled.
> >
> > An AI assistant helped find and check this change and drafted this
> > message.
> >
> > Link: https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays [1]
> > Signed-off-by: Hex Lindqvist <hex@freenixos.com>
> > ---
> >  drivers/bluetooth/btusb_qcom.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/bluetooth/btusb_qcom.c b/drivers/bluetooth/btusb_qcom.c
> > index cc4cfcde2afa..97be9078e045 100644
> > --- a/drivers/bluetooth/btusb_qcom.c
> > +++ b/drivers/bluetooth/btusb_qcom.c
> > @@ -533,7 +533,7 @@ struct qhci_vse_memdump {
> >       __le16 seqno;
> >       u8     subsys;
> >       union {
> > -             u8 segdata[0];
> > +             DECLARE_FLEX_ARRAY(u8, segdata);
> >               struct {
> >                       __le32 dump_size;
> >                       u8 first_segdata[];
>
> NAK. Please keep this as-is. since:
>
> 1) segdata[0] is a familiar GNU C idiom and, since it is only used as an offsetof() anchor, is more straightforward than the
>   DECLARE_FLEX_ARRAY() expansion.
>
> 2) I guess this kind of isolated cleanup may not be welcome.As noted in Documentation/process/maintainer-netdev.rst, simple cleanups outside
>    the context of other work are discouraged

While this maybe true if the above code does produce new warnings then
it needs to be fixed anyway, from the commit message it doesn't
mention any build warning but that perhaps is because it is enclosed
into a union which mask it or something, anyway trainling variable
length should be accompany with __counted_by; so the compiler can do
bounds checking.

-- 
Luiz Augusto von Dentz

Re: [PATCH] Bluetooth: btusb: Use DECLARE_FLEX_ARRAY() for memdump segment data

[Luiz Augusto von Dentz]

Hi Zijun,

On Mon, Nov 9, 2026 at 10:35 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Zijun,
>
> On Mon, Nov 9, 2026 at 8:21 AM Zijun Hu <zijun.hu@oss.qualcomm.com> wrote:
> >
> > On 11/8/2026 12:20 PM, Hex Lindqvist wrote:
> > > struct qhci_vse_memdump declares segdata as a zero-length array in a
> > > union. Zero-length arrays are deprecated [1], so use DECLARE_FLEX_ARRAY()
> > > instead.
> > >
> > > No functional change: segdata is only used with offsetof(). With debug
> > > info stripped, btusb.o is byte-for-byte identical before and after,
> > > built with GCC 16 and Clang 21 on x86_64 and GCC 16 on arm64, with
> > > UBSAN_BOUNDS and FORTIFY_SOURCE enabled.
> > >
> > > An AI assistant helped find and check this change and drafted this
> > > message.
> > >
> > > Link: https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays [1]
> > > Signed-off-by: Hex Lindqvist <hex@freenixos.com>
> > > ---
> > >  drivers/bluetooth/btusb_qcom.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/bluetooth/btusb_qcom.c b/drivers/bluetooth/btusb_qcom.c
> > > index cc4cfcde2afa..97be9078e045 100644
> > > --- a/drivers/bluetooth/btusb_qcom.c
> > > +++ b/drivers/bluetooth/btusb_qcom.c
> > > @@ -533,7 +533,7 @@ struct qhci_vse_memdump {
> > >       __le16 seqno;
> > >       u8     subsys;
> > >       union {
> > > -             u8 segdata[0];
> > > +             DECLARE_FLEX_ARRAY(u8, segdata);
> > >               struct {
> > >                       __le32 dump_size;
> > >                       u8 first_segdata[];
> >
> > NAK. Please keep this as-is. since:
> >
> > 1) segdata[0] is a familiar GNU C idiom and, since it is only used as an offsetof() anchor, is more straightforward than the
> >   DECLARE_FLEX_ARRAY() expansion.

Maybe not DECLARE_FLEX_ARRAY, but [0] is not recommended for vla see
the Link tag, in fact the first_segdata[] does follow it so this needs
to be fixed anyway.

> > 2) I guess this kind of isolated cleanup may not be welcome.As noted in Documentation/process/maintainer-netdev.rst, simple cleanups outside
> >    the context of other work are discouraged
>
> While this maybe true if the above code does produce new warnings then
> it needs to be fixed anyway, from the commit message it doesn't
> mention any build warning but that perhaps is because it is enclosed
> into a union which mask it or something, anyway trainling variable
> length should be accompany with __counted_by; so the compiler can do
> bounds checking.
>
> --
> Luiz Augusto von Dentz



-- 
Luiz Augusto von Dentz

Re: [PATCH] Bluetooth: btusb: Use DECLARE_FLEX_ARRAY() for memdump segment data

[Hex Lindqvist]

Hi Luiz, Zijun,

Thank you both for looking at this, and Paul for the review.

On Mon, Nov 9, 2026 at 10:39 AM Luiz Augusto von Dentz wrote:
> On Mon, Nov 9, 2026 at 10:35 AM Luiz Augusto von Dentz wrote:
>> While this maybe true if the above code does produce new warnings then
>> it needs to be fixed anyway, from the commit message it doesn't
>> mention any build warning but that perhaps is because it is enclosed
>> into a union which mask it or something, anyway trainling variable
>> length should be accompany with __counted_by; so the compiler can do
>> bounds checking.

There is no build warning, with or without the union; the patch was
only about the zero-length array being deprecated. __counted_by does
not fit here: the struct has no count field, and the segment length
comes from skb->len.

> Maybe not DECLARE_FLEX_ARRAY, but [0] is not recommended for vla see
> the Link tag, in fact the first_segdata[] does follow it so this needs
> to be fixed anyway.

As Zijun says, segdata is only an offsetof() anchor, so it can go
together with the union:

	struct qhci_vse_memdump {
		__le16 seqno;
		u8     subsys;
		__le32 dump_size;
		u8     first_segdata[];
	} __packed;

	#define QHCI_MEMDUMP_HDR_LEN	offsetof(struct qhci_vse_memdump, dump_size)

The header is pulled with QHCI_MEMDUMP_HDR_LEN, the first segment's
dump_size with sizeof(md_vse->dump_size), and the kernel-doc gains a
line saying that middle and last segments carry their payload right
after @subsys. The generated code does not change.

Zijun, would that work for you? If so, I will send it as v2.

Thanks,
Hex