Re: [PATCH 05/18] rust: add bindings for hash.h

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Unintended exposure of <linux/hash.h> to Rust bindings.
- [Low] Alphabetical sorting rules are violated in bindings_helper.h and helpers.c.
--

commit d4762d094c0da15881ab9c843fc2316ba4792255
Author: Alistair Francis <alistair.francis@wdc.com>

rust: add bindings for hash.h

This commit exposes crypto_shash_descsize(), crypto_shash_digestsize(),
and crypto_free_shash() to Rust by adding them to the C helpers and
updating the bindings include lists.

> diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
> index 446dbeaf08668..d73142078240f 100644
> --- a/rust/bindings/bindings_helper.h
> +++ b/rust/bindings/bindings_helper.h
> @@ -30,6 +30,7 @@
>  
>  #include <linux/acpi.h>
>  #include <linux/gpu_buddy.h>
> +#include <crypto/hash.h>
>  #include <drm/drm_device.h>
>  #include <drm/drm_drv.h>

This isn't a bug, but does this addition break the alphabetical sorting of
the includes?  It looks like <crypto/hash.h> is being inserted between
<linux/gpu_buddy.h> and <drm/drm_device.h>.

[ ... ]

> @@ -60,6 +61,7 @@
>  #include <linux/file.h>
>  #include <linux/firmware.h>
>  #include <linux/fs.h>
> +#include <linux/hash.h>
>  #include <linux/i2c.h>

The commit message mentions adding bindings for crypto/hash.h.  Is the
addition of linux/hash.h intended here?

It doesn't appear that utilities from linux/hash.h are being used, which
could unnecessarily increase bindgen execution time and pollute the
Rust namespace.

> diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
> index 625921e27dfbc..6372e14f8419c 100644
> --- a/rust/helpers/helpers.c
> +++ b/rust/helpers/helpers.c
> @@ -60,6 +60,7 @@
>  #include "dma-resv.c"
>  #include "drm.c"
>  #include "err.c"
> +#include "hash.c"
>  #include "irq.c"
>  #include "fs.c"
>  #include "gpu.c"

This isn't a bug, but does inserting hash.c here also bypass alphabetical
sorting?

While it is placed before irq.c, both fs.c and gpu.c appear further down in
the existing list, so placing hash.c after gpu.c might keep this block more
properly ordered.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260508031710.514574-1-alistair.francis@wdc.com?part=5