[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260129152201.389fac74@kernel.org>
Date: Thu, 29 Jan 2026 15:22:01 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: David Yang <mmyangfl@...il.com>
Cc: netdev@...r.kernel.org, Vladimir Oltean <vladimir.oltean@....com>,
Claudiu Manoil <claudiu.manoil@....com>, Alexandre Belloni
<alexandre.belloni@...tlin.com>, UNGLinuxDriver@...rochip.com, Andrew Lunn
<andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet
<edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon Horman
<horms@...nel.org>, Russell King <linux@...linux.org.uk>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 1/3] net: dsa: sync dsa_mall_policer_tc_entry
with FLOW_ACTION_POLICE
On Mon, 26 Jan 2026 14:13:29 +0800 David Yang wrote:
> - policer->rate_bytes_per_sec = act->police.rate_bytes_ps;
> - policer->burst = act->police.burst;
> + /* so sad, flow_offload.h did not export the type of act->police, and
> + * it's a nightmare to copy it field by field
> + */
> + static_assert(sizeof(act->police) == sizeof(*policer));
> + memcpy(policer, &act->police, sizeof(*policer));
This is of course an unacceptable hack. Nobody will realize that
there's a layout dependency here, not to mention struct randomization.
If someone adds fields presumably they will have to update
dsa_mall_policer_tc_entry_type() anyway, so we aren't saving much with this hack
Powered by blists - more mailing lists