netdev - Re: [PATCH V4 net-next 3/9] net: ena: add explicit casting to variables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKgT0Ueaa-63KGuvhDMT+emk4UoXPUW4SFB8GbxhNj4N5SDwYg@mail.gmail.com>
Date:   Mon, 7 Dec 2020 11:00:34 -0800
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     akiyano@...zon.com
Cc:     David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Netdev <netdev@...r.kernel.org>, dwmw@...zon.com,
        zorik@...zon.com, matua@...zon.com, saeedb@...zon.com,
        msw@...zon.com, aliguori@...zon.com, nafea@...zon.com,
        gtzalik@...zon.com, netanel@...zon.com, alisaidi@...zon.com,
        benh@...zon.com, ndagan@...zon.com, shayagr@...zon.com,
        "Jubran, Samih" <sameehj@...zon.com>, Ido Segev <idose@...zon.com>,
        Igor Chauskin <igorch@...zon.com>
Subject: Re: [PATCH V4 net-next 3/9] net: ena: add explicit casting to variables

On Fri, Dec 4, 2020 at 4:15 AM <akiyano@...zon.com> wrote:
>
> From: Arthur Kiyanovski <akiyano@...zon.com>
>
> This patch adds explicit casting to some implicit conversions in the ena
> driver. The implicit conversions fail some of our static checkers that
> search for accidental conversions in our driver.
> Adding this cast won't affect the end results, and would sooth the
> checkers.
>
> Signed-off-by: Ido Segev <idose@...zon.com>
> Signed-off-by: Igor Chauskin <igorch@...zon.com>
> Signed-off-by: Shay Agroskin <shayagr@...zon.com>
> Signed-off-by: Arthur Kiyanovski <akiyano@...zon.com>
> ---
>  drivers/net/ethernet/amazon/ena/ena_com.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/amazon/ena/ena_com.c b/drivers/net/ethernet/amazon/ena/ena_com.c
> index e168edf3c930..7910d8e68a99 100644
> --- a/drivers/net/ethernet/amazon/ena/ena_com.c
> +++ b/drivers/net/ethernet/amazon/ena/ena_com.c
> @@ -1369,7 +1369,7 @@ int ena_com_execute_admin_command(struct ena_com_admin_queue *admin_queue,
>                                    "Failed to submit command [%ld]\n",
>                                    PTR_ERR(comp_ctx));
>
> -               return PTR_ERR(comp_ctx);
> +               return (int)PTR_ERR(comp_ctx);
>         }
>
>         ret = ena_com_wait_and_process_admin_cq(comp_ctx, admin_queue);

I'm not a big fan of resolving it this way as we are going to end up
with the pattern throughout the kernel if this is really needed. It
might make more sense to either come up with a new define that returns
int instead of long, or to tweak the existing PTR_ERR define so that
it returns an int instead of a long.

An alternative here would be to just pass PTR_ERR into ret and then
process it that way within this if block. As it stands the comparison
to ERR_PTR(-ENODEV) doesn't read very well anyway.

> @@ -1595,7 +1595,7 @@ int ena_com_set_aenq_config(struct ena_com_dev *ena_dev, u32 groups_flag)
>  int ena_com_get_dma_width(struct ena_com_dev *ena_dev)
>  {
>         u32 caps = ena_com_reg_bar_read32(ena_dev, ENA_REGS_CAPS_OFF);
> -       int width;
> +       u32 width;
>
>         if (unlikely(caps == ENA_MMIO_READ_TIMEOUT)) {
>                 netdev_err(ena_dev->net_device, "Reg read timeout occurred\n");
> @@ -2266,7 +2266,7 @@ int ena_com_set_dev_mtu(struct ena_com_dev *ena_dev, int mtu)
>         cmd.aq_common_descriptor.opcode = ENA_ADMIN_SET_FEATURE;
>         cmd.aq_common_descriptor.flags = 0;
>         cmd.feat_common.feature_id = ENA_ADMIN_MTU;
> -       cmd.u.mtu.mtu = mtu;
> +       cmd.u.mtu.mtu = (u32)mtu;
>
>         ret = ena_com_execute_admin_command(admin_queue,
>                                             (struct ena_admin_aq_entry *)&cmd,

Wouldn't it make more sense to define mtu as a u32 in the first place
and address this in the function that calls this rather than doing the
cast at the last minute?

> @@ -2689,7 +2689,7 @@ int ena_com_indirect_table_set(struct ena_com_dev *ena_dev)
>                 return ret;
>         }
>
> -       cmd.control_buffer.length = (1ULL << rss->tbl_log_size) *
> +       cmd.control_buffer.length = (u32)(1ULL << rss->tbl_log_size) *
>                 sizeof(struct ena_admin_rss_ind_table_entry);
>
>         ret = ena_com_execute_admin_command(admin_queue,
> @@ -2712,7 +2712,7 @@ int ena_com_indirect_table_get(struct ena_com_dev *ena_dev, u32 *ind_tbl)
>         u32 tbl_size;
>         int i, rc;
>
> -       tbl_size = (1ULL << rss->tbl_log_size) *
> +       tbl_size = (u32)(1ULL << rss->tbl_log_size) *
>                 sizeof(struct ena_admin_rss_ind_table_entry);
>
>         rc = ena_com_get_feature_ex(ena_dev, &get_resp,

For these last two why not make it 1u instead of 1ull for the bit
being shifted? At least that way you are not implying possible
truncation in the conversion.