netdev - Re: [RFC PATCH iwl-next 1/6] ip_tunnel: use a separate struct to store tunnel params in the kernel

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]

Date: Mon, 5 Jun 2023 11:23:53 +0200
From: Simon Horman <simon.horman@...igine.com>
To: Marcin Szycik <marcin.szycik@...ux.intel.com>
Cc: intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org,
	wojciech.drewek@...el.com, michal.swiatkowski@...ux.intel.com,
	alexandr.lobakin@...el.com, davem@...emloft.net, kuba@...nel.org,
	jiri@...nulli.us, pabeni@...hat.com, jesse.brandeburg@...el.com,
	idosch@...dia.com
Subject: Re: [RFC PATCH iwl-next 1/6] ip_tunnel: use a separate struct to
 store tunnel params in the kernel

On Thu, Jun 01, 2023 at 03:19:24PM +0200, Marcin Szycik wrote:
> From: Alexander Lobakin <alexandr.lobakin@...el.com>
> 
> Unlike IPv6 tunnels which use purely-kernel __ip6_tnl_parm structure
> to store params inside the kernel, IPv4 tunnel code uses the same
> ip_tunnel_parm which is being used to talk with the userspace.
> This makes it difficult to alter or add any fields or use a
> different format for whatever data.
> Define struct ip_tunnel_parm_kern, a 1:1 copy of ip_tunnel_parm for
> now, and use it throughout the code. The two places where the latter
> is used to interact with the userspace, now do a conversion from one
> type to another, with manual field-by-field assignments.
> Must be done at once, since ip_tunnel::parms is being used in most
> of those places.
> 
> Signed-off-by: Alexander Lobakin <alexandr.lobakin@...el.com>
> Signed-off-by: Marcin Szycik <marcin.szycik@...ux.intel.com>

Reviewed-by: Simon Horman <simon.horman@...igine.com>