similar to: [PATCH][next] drm/virtio: Use struct_size() helper in kmalloc()

Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes, in particular in the context in which this code is being used. So, replace the following form: sizeof(*kind) + sizeof(*kind->data) * mmu->kind_nr; with: struct_size(kind, data, mmu->kind_nr) This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A.

One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct nvif_mmu_kind_v0 { ... __u8 data[]; }; Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. So, replace

One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct virtio_scsi { ... struct virtio_scsi_vq req_vqs[]; }; Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes.

One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct virtio_scsi { ... struct virtio_scsi_vq req_vqs[]; }; Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes.

Hi Gustavo, On Thu, Nov 16, 2023 at 12:11:43PM -0600, Gustavo A. R. Silva wrote: > Fake flexible arrays (zero-length and one-element arrays) are deprecated, > and should be replaced by flexible-array members. So, replace > zero-length array with a flexible-array member in `struct > PACKED_REGISTRY_TABLE`. > > Also annotate array `entries` with `__counted_by()` to prepare for

Fake flexible arrays (zero-length and one-element arrays) are deprecated, and should be replaced by flexible-array members. So, replace zero-length array with a flexible-array member in `struct PACKED_REGISTRY_TABLE`. Also annotate array `entries` with `__counted_by()` to prepare for the coming implementation by GCC and Clang of the `__counted_by` attribute. Flexible array members annotated with

Gustavo, > One of the more common cases of allocation size calculations is finding > the size of a structure that has a zero-sized array at the end, along > with memory for some number of elements for that array. For example: Applied to 5.4/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering

On 2/25/20 08:17, Jani Nikula wrote: > On Tue, 25 Feb 2020, "Gustavo A. R. Silva" <gustavo at embeddedor.com> wrote: >> The current codebase makes use of the zero-length array language >> extension to the C90 standard, but the preferred mechanism to declare >> variable-length types such as these ones is a flexible array member[1][2], >> introduced in C99:

From: Kees Cook <keescook at chromium.org> [ Upstream commit 25feda6fbd0cfefcb69308fb20d4d4815a107c5e ] More arrays (and arguments) for dcpd were set to 16, when it looks like DP_RECEIVER_CAP_SIZE (15) should be used. Fix the remaining cases, seen with GCC 13: ../drivers/gpu/drm/nouveau/nvif/outp.c: In function 'nvif_outp_acquire_dp': ../include/linux/fortify-string.h:57:33:

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to ?__read_overflow2_field? declared with attribute warning: detected read beyond

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not

On Mon, Sep 25, 2023 at 08:30:30AM +0200, Christian K?nig wrote: > Am 22.09.23 um 19:41 schrieb Alex Deucher: > > On Fri, Sep 22, 2023 at 1:32?PM Kees Cook <keescook at chromium.org> wrote: > > > Prepare for the coming implementation by GCC and Clang of the __counted_by > > > attribute. Flexible array members annotated with __counted_by can have > > >

On Mon, Sep 25, 2023 at 08:30:30AM +0200, Christian K?nig wrote: > Am 22.09.23 um 19:41 schrieb Alex Deucher: > > On Fri, Sep 22, 2023 at 1:32?PM Kees Cook <keescook at chromium.org> wrote: > > > Prepare for the coming implementation by GCC and Clang of the __counted_by > > > attribute. Flexible array members annotated with __counted_by can have > > >

On Mon, Sep 25, 2023 at 08:30:30AM +0200, Christian K?nig wrote: > Am 22.09.23 um 19:41 schrieb Alex Deucher: > > On Fri, Sep 22, 2023 at 1:32?PM Kees Cook <keescook at chromium.org> wrote: > > > Prepare for the coming implementation by GCC and Clang of the __counted_by > > > attribute. Flexible array members annotated with __counted_by can have > > >

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c | 1 + 1 file changed, 1 insertion(+) diff --git

In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple of warnings by explicitly adding a couple of break statements instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 1 +

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 1 + 1 file changed, 1 insertion(+) diff --git

Zero-length arrays are deprecated[1] and we are moving towards adopting C99 flexible-array members instead. So, replace zero-length array declaration in struct nvfw_hs_load_header_v2 with flex-array member. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [2]. Link:

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to