Re: [Nouveau] [PATCH][next] treewide: Replace zero-length arrays with flexible-array members

2022-02-20 Thread Kees Cook
On Tue, Feb 15, 2022 at 11:47:43AM -0600, Gustavo A. R. Silva wrote:
> There is a regular need in the kernel to provide a way to declare
> having a dynamically sized set of trailing elements in a structure.
> Kernel code should always use “flexible array members”[1] for these
> cases. The older style of one-element or zero-length arrays should
> no longer be used[2].
> 
> This code was transformed with the help of Coccinelle:
> (next-20220214$ spatch --jobs $(getconf _NPROCESSORS_ONLN) --sp-file 
> script.cocci --include-headers --dir . > output.patch)
> 
> @@
> identifier S, member, array;
> type T1, T2;
> @@
> 
> struct S {
>   ...
>   T1 member;
>   T2 array[
> - 0
>   ];
> };

These all look trivially correct to me. Only two didn't have the end of
the struct visible in the patch, and checking those showed them to be
trailing members as well, so:

Reviewed-by: Kees Cook 

-- 
Kees Cook


[Nouveau] [PATCH][next] treewide: Replace zero-length arrays with flexible-array members

2022-02-20 Thread Gustavo A. R. Silva
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use “flexible array members”[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].

This code was transformed with the help of Coccinelle:
(next-20220214$ spatch --jobs $(getconf _NPROCESSORS_ONLN) --sp-file 
script.cocci --include-headers --dir . > output.patch)

@@
identifier S, member, array;
type T1, T2;
@@

struct S {
  ...
  T1 member;
  T2 array[
- 0
  ];
};

UAPI and wireless changes were intentionally excluded from this patch
and will be sent out separately.

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] 
https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays

Link: https://github.com/KSPP/linux/issues/78
Signed-off-by: Gustavo A. R. Silva 
---
Hi all,

I'm expecting to carry this patch in my tree, so it'd be great to
get some Acks. And given the size of the patch, I'm only sending
this to mailing lists.

Thanks!

 arch/alpha/include/asm/hwrpb.h|  2 +-
 arch/ia64/include/asm/sal.h   |  2 +-
 arch/s390/include/asm/ccwgroup.h  |  2 +-
 arch/s390/include/asm/chsc.h  |  2 +-
 arch/s390/include/asm/eadm.h  |  2 +-
 arch/s390/include/asm/fcx.h   |  4 ++--
 arch/s390/include/asm/idals.h |  2 +-
 arch/s390/include/asm/sclp.h  |  2 +-
 arch/s390/include/asm/sysinfo.h   |  6 +++---
 arch/sh/include/asm/thread_info.h |  2 +-
 arch/sparc/include/asm/vio.h  | 10 +-
 arch/um/include/shared/net_kern.h |  2 +-
 arch/x86/include/asm/microcode_amd.h  |  2 +-
 arch/x86/include/asm/microcode_intel.h|  4 ++--
 arch/x86/include/asm/pci.h|  2 +-
 arch/x86/include/asm/pci_x86.h|  2 +-
 arch/xtensa/include/asm/bootparam.h   |  2 +-
 drivers/crypto/caam/pdb.h |  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|  2 +-
 drivers/gpu/drm/nouveau/include/nvfw/hs.h |  2 +-
 .../hwtracing/coresight/coresight-config.h|  2 +-
 drivers/misc/bcm-vk/bcm_vk.h  |  2 +-
 .../misc/habanalabs/include/common/cpucp_if.h |  6 +++---
 .../habanalabs/include/gaudi/gaudi_packets.h  |  4 ++--
 .../habanalabs/include/goya/goya_packets.h|  4 ++--
 .../net/ethernet/freescale/enetc/enetc_hw.h   |  2 +-
 drivers/net/ethernet/i825xx/sun3_82586.h  |  2 +-
 .../net/ethernet/marvell/octeontx2/af/npc.h   |  6 +++---
 drivers/net/ethernet/qlogic/qed/qed_mfw_hsi.h |  2 +-
 drivers/net/ethernet/ti/davinci_mdio.c|  2 +-
 drivers/scsi/dpt/dpti_i2o.h   |  2 +-
 drivers/scsi/elx/libefc_sli/sli4.h| 20 +--
 drivers/scsi/mpi3mr/mpi3mr.h  |  2 +-
 drivers/scsi/qla2xxx/qla_bsg.h|  4 ++--
 drivers/scsi/qla2xxx/qla_def.h|  2 +-
 drivers/scsi/qla2xxx/qla_edif_bsg.h   |  4 ++--
 drivers/scsi/qla2xxx/qla_fw.h |  2 +-
 drivers/scsi/qla4xxx/ql4_fw.h |  2 +-
 drivers/staging/r8188eu/include/ieee80211.h   |  6 +++---
 drivers/staging/r8188eu/include/rtw_cmd.h | 10 +-
 drivers/staging/rtl8712/rtl871x_cmd.h |  8 
 drivers/staging/rtl8723bs/include/ieee80211.h |  2 +-
 drivers/staging/rtl8723bs/include/rtw_cmd.h   |  2 +-
 .../include/linux/raspberrypi/vchiq.h |  2 +-
 drivers/visorbus/vbuschannel.h|  2 +-
 fs/cifs/ntlmssp.h |  2 +-
 fs/ext4/fast_commit.h |  4 ++--
 fs/ksmbd/ksmbd_netlink.h  |  2 +-
 fs/ksmbd/ntlmssp.h|  6 +++---
 fs/ksmbd/smb2pdu.h|  8 
 fs/ksmbd/transport_rdma.c |  2 +-
 fs/ksmbd/xattr.h  |  2 +-
 fs/xfs/scrub/attr.h   |  2 +-
 include/acpi/actbl2.h |  2 +-
 include/asm-generic/tlb.h |  4 ++--
 include/linux/greybus/greybus_manifest.h  |  4 ++--
 include/linux/greybus/hd.h|  2 +-
 include/linux/greybus/module.h|  2 +-
 include/linux/i3c/ccc.h   |  6 +++---
 include/linux/mlx5/mlx5_ifc_fpga.h|  2 +-
 include/linux/platform_data/brcmfmac.h|  2 +-
 .../linux/platform_data/cros_ec_commands.h|  2 +-
 include/net/bluetooth/mgmt.h  |  2 +-
 include/net/ioam6.h   |  2 +-
 include/sound/sof/channel_map.h   |  4 ++--
 scripts/dtc/libfdt/fdt.h  |  4 ++--
 sound/soc/intel/atom/sst-mfld-dsp.h   |  4 ++--
 sound/soc/intel/skylake/skl-topology.h|  2 +-
 tools/lib/perf/include/perf/event.h   |  2 +-
 69 files 

Re: [Nouveau] [PATCH][next] treewide: Replace zero-length arrays with flexible-array members

2022-02-20 Thread Gustavo A. R. Silva
On Tue, Feb 15, 2022 at 10:17:40AM -0800, Kees Cook wrote:
> On Tue, Feb 15, 2022 at 11:47:43AM -0600, Gustavo A. R. Silva wrote:
> > There is a regular need in the kernel to provide a way to declare
> > having a dynamically sized set of trailing elements in a structure.
> > Kernel code should always use “flexible array members”[1] for these
> > cases. The older style of one-element or zero-length arrays should
> > no longer be used[2].
> > 
> > This code was transformed with the help of Coccinelle:
> > (next-20220214$ spatch --jobs $(getconf _NPROCESSORS_ONLN) --sp-file 
> > script.cocci --include-headers --dir . > output.patch)
> > 
> > @@
> > identifier S, member, array;
> > type T1, T2;
> > @@
> > 
> > struct S {
> >   ...
> >   T1 member;
> >   T2 array[
> > - 0
> >   ];
> > };
> 
> These all look trivially correct to me. Only two didn't have the end of
> the struct visible in the patch, and checking those showed them to be
> trailing members as well, so:
> 
> Reviewed-by: Kees Cook 

I'll add this to my -next tree.

Thanks!
--
Gustavo


Re: [Nouveau] [PATCH][next] treewide: Replace zero-length arrays with flexible-array members

2022-02-20 Thread Gustavo A. R. Silva
On Tue, Feb 15, 2022 at 09:19:29PM +0200, Leon Romanovsky wrote:
> On Tue, Feb 15, 2022 at 01:21:10PM -0600, Gustavo A. R. Silva wrote:
> > On Tue, Feb 15, 2022 at 10:17:40AM -0800, Kees Cook wrote:
> > > On Tue, Feb 15, 2022 at 11:47:43AM -0600, Gustavo A. R. Silva wrote:
> > > 
> > > These all look trivially correct to me. Only two didn't have the end of
> > > the struct visible in the patch, and checking those showed them to be
> > > trailing members as well, so:
> > > 
> > > Reviewed-by: Kees Cook 
> > 
> > I'll add this to my -next tree.
> 
> I would like to ask you to send mlx5 patch separately to netdev. We are 
> working
> to delete that file completely and prefer to avoid from unnecessary merge 
> conflicts.

Oh OK. Sure thing; I will do so.

Thanks
--
Gustavo


Re: [Nouveau] [PATCH][next] treewide: Replace zero-length arrays with flexible-array members

2022-02-20 Thread Leon Romanovsky
On Tue, Feb 15, 2022 at 01:21:10PM -0600, Gustavo A. R. Silva wrote:
> On Tue, Feb 15, 2022 at 10:17:40AM -0800, Kees Cook wrote:
> > On Tue, Feb 15, 2022 at 11:47:43AM -0600, Gustavo A. R. Silva wrote:
> > > There is a regular need in the kernel to provide a way to declare
> > > having a dynamically sized set of trailing elements in a structure.
> > > Kernel code should always use “flexible array members”[1] for these
> > > cases. The older style of one-element or zero-length arrays should
> > > no longer be used[2].
> > > 
> > > This code was transformed with the help of Coccinelle:
> > > (next-20220214$ spatch --jobs $(getconf _NPROCESSORS_ONLN) --sp-file 
> > > script.cocci --include-headers --dir . > output.patch)
> > > 
> > > @@
> > > identifier S, member, array;
> > > type T1, T2;
> > > @@
> > > 
> > > struct S {
> > >   ...
> > >   T1 member;
> > >   T2 array[
> > > - 0
> > >   ];
> > > };
> > 
> > These all look trivially correct to me. Only two didn't have the end of
> > the struct visible in the patch, and checking those showed them to be
> > trailing members as well, so:
> > 
> > Reviewed-by: Kees Cook 
> 
> I'll add this to my -next tree.

I would like to ask you to send mlx5 patch separately to netdev. We are working
to delete that file completely and prefer to avoid from unnecessary merge 
conflicts.

Thanks

> 
> Thanks!
> --
> Gustavo


Re: [Nouveau] [PATCH][next] treewide: Replace zero-length arrays with flexible-array members

2022-02-20 Thread Rafael J. Wysocki
On Tue, Feb 15, 2022 at 8:24 PM Gustavo A. R. Silva
 wrote:
>
> On Tue, Feb 15, 2022 at 09:19:29PM +0200, Leon Romanovsky wrote:
> > On Tue, Feb 15, 2022 at 01:21:10PM -0600, Gustavo A. R. Silva wrote:
> > > On Tue, Feb 15, 2022 at 10:17:40AM -0800, Kees Cook wrote:
> > > > On Tue, Feb 15, 2022 at 11:47:43AM -0600, Gustavo A. R. Silva wrote:
> > > >
> > > > These all look trivially correct to me. Only two didn't have the end of
> > > > the struct visible in the patch, and checking those showed them to be
> > > > trailing members as well, so:
> > > >
> > > > Reviewed-by: Kees Cook 
> > >
> > > I'll add this to my -next tree.
> >
> > I would like to ask you to send mlx5 patch separately to netdev. We are 
> > working
> > to delete that file completely and prefer to avoid from unnecessary merge 
> > conflicts.
>
> Oh OK. Sure thing; I will do so.

Can you also send the ACPI patch separately, please?

We would like to route it through the upstream ACPICA code base.


Re: [Nouveau] [PATCH][next] treewide: Replace zero-length arrays with flexible-array members

2022-02-20 Thread Gustavo A. R. Silva
On Wed, Feb 16, 2022 at 08:05:47PM +0100, Rafael J. Wysocki wrote:
> On Tue, Feb 15, 2022 at 8:24 PM Gustavo A. R. Silva
>  wrote:
> 
> Can you also send the ACPI patch separately, please?
> 
> We would like to route it through the upstream ACPICA code base.

Yeah; no problem.

Thanks
--
Gustavo