linux-kernel - RE: [PATCH iwl-next v2 4/8] ice: allow overriding lan_en, lb

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] [day] [month] [year] [list]

Message-ID: <IA3PR11MB8986E6C10E42C5DD6DC717B9E5D1A@IA3PR11MB8986.namprd11.prod.outlook.com>
Date: Tue, 25 Nov 2025 08:59:49 +0000
From: "Loktionov, Aleksandr" <aleksandr.loktionov@...el.com>
To: "Slepecki, Jakub" <jakub.slepecki@...el.com>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Kitszel, Przemyslaw"
	<przemyslaw.kitszel@...el.com>, "Nguyen, Anthony L"
	<anthony.l.nguyen@...el.com>, "michal.swiatkowski@...ux.intel.com"
	<michal.swiatkowski@...ux.intel.com>
Subject: RE: [PATCH iwl-next v2 4/8] ice: allow overriding lan_en, lb_en in
 switch



> -----Original Message-----
> From: Slepecki, Jakub <jakub.slepecki@...el.com>
> Sent: Tuesday, November 25, 2025 9:35 AM
> To: intel-wired-lan@...ts.osuosl.org
> Cc: linux-kernel@...r.kernel.org; netdev@...r.kernel.org; Kitszel,
> Przemyslaw <przemyslaw.kitszel@...el.com>; Nguyen, Anthony L
> <anthony.l.nguyen@...el.com>; michal.swiatkowski@...ux.intel.com; Slepecki,
> Jakub <jakub.slepecki@...el.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@...el.com>
> Subject: [PATCH iwl-next v2 4/8] ice: allow overriding lan_en, lb_en in
> switch
> 
> Currently, lan_en and lb_en are determined based on switching mode,
> destination MAC, and the lookup type, action type and flags of the rule in
> question.  This gives little to no options for the user (such as
> ice_fltr.c) to enforce rules to behave in a specific way.
> 
> Such functionality is needed to work with pairs of rules, for example, when
> handling MAC forward to LAN together with MAC,VLAN forward to loopback rules
> pair.  This case could not be easily deduced in a context of a single filter
> without adding a specialized flag.
> 
> Instead of adding a specialized flag to mark special scenario rules, we add
> a slightly more generic flag to the lan_en and lb_en themselves for the
> ice_fltr.c to request specific destination flags later on, for example, to
> override value:
> 
>     struct ice_fltr_info fi;
>     fi.lb_en = ICE_FLTR_INFO_LB_LAN_FORCE_ENABLED;
>     fi.lan_en = ICE_FLTR_INFO_LB_LAN_FORCE_DISABLED;
> 
> Signed-off-by: Jakub Slepecki <jakub.slepecki@...el.com>
> 
> ---
> Dropping reviewed-by from Michał due to changes.
> 
> Changes in v2:
>   - Use FIELD_GET et al. when handling fi.lb_en and fi.lan_en.
>   - Rename /LB_LAN/s/_MASK/_M/ because one of uses would need to break
>     line.
> ---

...
 
>  	if (fi->flag & ICE_FLTR_TX_ONLY)
> -		fi->lan_en = false;
> +		lan_en = false;
> +	if (!FIELD_GET(ICE_FLTR_INFO_LB_LAN_FORCE_M, fi->lb_en))
> +		FIELD_MODIFY(ICE_FLTR_INFO_LB_LAN_VALUE_M, &fi->lb_en,
> lb_en);
> +	if (!FIELD_GET(ICE_FLTR_INFO_LB_LAN_FORCE_M, fi->lan_en))
> +		FIELD_MODIFY(ICE_FLTR_INFO_LB_LAN_VALUE_M, &fi->lan_en,
fi->lb_en and fi->lan_en are declared as bool in struct ice_fltr_info, but you are now treating them as bitfields using FIELD_GET and FIELD_MODIFY.

I realize it could be something like:
struct ice_fltr_info {
    ...
    u8 lb_lan_flags; /* bitfield: value + force */
    ...
};
#define ICE_FLTR_INFO_LB_LAN_VALUE_M    BIT(0)
#define ICE_FLTR_INFO_LB_LAN_FORCE_M    BIT(1)
#define ICE_FLTR_INFO_LB_LAN_FORCE_ENABLED \
    (FIELD_PREP_CONST(ICE_FLTR_INFO_LB_LAN_VALUE_M, 1) | \
     FIELD_PREP_CONST(ICE_FLTR_INFO_LB_LAN_FORCE_M, 1))
#define ICE_FLTR_INFO_LB_LAN_FORCE_DISABLED \
    (FIELD_PREP_CONST(ICE_FLTR_INFO_LB_LAN_FORCE_M, 1))

...