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: <37cf9088-b050-4788-b870-f28f0fb58b9e@intel.com>
Date: Tue, 11 Jun 2024 13:09:47 +0200
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Michael Chan <michael.chan@...adcom.com>
CC: <netdev@...r.kernel.org>, <edumazet@...gle.com>, <kuba@...nel.org>,
	<pabeni@...hat.com>, <andrew.gospodarek@...adcom.com>, <horms@...nel.org>,
	Somnath Kotur <somnath.kotur@...adcom.com>, Pavan Chebbi
	<pavan.chebbi@...adcom.com>, <davem@...emloft.net>
Subject: Re: [PATCH net v2] bnxt_en: Cap the size of HWRM_PORT_PHY_QCFG
 forwarded response

On 6/11/24 01:52, Michael Chan wrote:
> On Mon, Jun 10, 2024 at 7:00 AM Michael Chan <michael.chan@...adcom.com> wrote:
>>
>> On Mon, Jun 10, 2024 at 4:38 AM Przemek Kitszel
>> <przemyslaw.kitszel@...el.com> wrote:
>>>
>>> I assume that the first 96 bytes of the current
>>> struct hwrm_port_phy_qcfg are the same as here; with that you could wrap
>>> those there by struct_group_tagged, giving the very same name as here,
>>> but without replicating all the content.
>>
>> Except for the valid bit at the end of the struct.  Let me see if I
>> can define the struct_group thing for 95 bytes and add the valid bit
>> here.  Thanks.
>>
> 
> The struct_group_tagged() idea works in general.  However, the
> hwrm_port_phy_qcfg_output struct is generated from yaml and it
> contains a lot of #define within the structure.  So it looks like this
> with struct_group_tagged added:
> 
> struct hwrm_port_phy_qcfg_output {
>          struct_group_tagged(hwrm_port_phy_qcfg_output_legacy, legacy,
>                  __le16  error_code;
>                  __le16  req_type;
>                  __le16  seq_id;
>                  __le16  resp_len;
>                  u8      link;
>          #define PORT_PHY_QCFG_RESP_LINK_NO_LINK 0x0UL
>          #define PORT_PHY_QCFG_RESP_LINK_SIGNAL  0x1UL
>          #define PORT_PHY_QCFG_RESP_LINK_LINK    0x2UL
> ....
>          );
> ....
> };
> 
> The #define within the struct_group generates a lot of warnings with make C=1:
> 
>    CC [M]  drivers/net/ethernet/broadcom/bnxt/bnxt.o
>    CHECK   drivers/net/ethernet/broadcom/bnxt/bnxt.c
> drivers/net/ethernet/broadcom/bnxt/bnxt.c: note: in included file:
> drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h:4211:9: warning:
> directive in macro's argument list
> 
> Because it's a generated file, it's hard to make the drastic change to

is this generated as part of upstream build process or just manually?

> move all the #define macros.  Maybe in the future when we restructure
> these generated structs, we can do it in a better way.

You could also just split struct into two and combine them (packed)
into hwrm_port_phy_qcfg_output and add compat one as combination of
hwrm_port_phy_qcfg_output + valid bit

If you don't want to do so, please at least document in code that only 
the first 95 bytes match and the last one is different

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ