[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: Bluetooth: btusb: Use DECLARE_FLEX_ARRAY() for memdump segment data

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/series/1205193/

---Test result---

Test Summary:
CheckPatch                    PASS      0.83 seconds
VerifyFixes                   PASS      0.13 seconds
VerifySignedoff               PASS      0.13 seconds
GitLint                       PASS      0.35 seconds
SubjectPrefix                 PASS      0.13 seconds
BuildKernel                   PASS      31.33 seconds
CheckAllWarning               PASS      35.05 seconds
CheckSparse                   PASS      37.98 seconds
BuildKernel32                 PASS      31.13 seconds
CheckKernelLLVM               PASS      32.59 seconds
TestRunnerSetup               PASS      741.78 seconds
IncrementalBuild              PASS      29.21 seconds



https://github.com/bluez/bluetooth-next/pull/1088

---
Regards,
Linux Bluetooth

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

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

[Zijun Hu]

On 11/10/2026 6:56 AM, Hex Lindqvist wrote:
> 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.

Hi Luiz, Hex,

Let me give a unified reply here.

I'd prefer to keep it as-is, since:

1) The union maps the memdump layout: for the first segment, a __le32
 dump_size (the total memdump size) follows @subsys, then the data;
 for other segments, the data follows @subsys directly. Hex's
 flattened v2 is wrong for all non-first segments.

2) The current definition builds clean with W=1 and passes
 checkpatch.pl --strict, while changing segdata[0] to segdata[]
 causes build warnings.

3) The struct is the simplest and most straightforward form; it is
 only used to parse memdump frames, so it doesn't have the problem
 DECLARE_FLEX_ARRAY() solves.