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
| ||
|
Message-ID: <20190401181328.2c83a197@cakuba.hsd1.ca.comcast.net> Date: Mon, 1 Apr 2019 18:13:28 -0700 From: Jakub Kicinski <jakub.kicinski@...ronome.com> To: David Miller <davem@...emloft.net> Cc: netdev@...r.kernel.org, oss-drivers@...ronome.com Subject: Re: [PATCH net 0/2] nfp: flower: fix matching and pushing vlan CFI bit On Mon, 01 Apr 2019 18:03:00 -0700 (PDT), David Miller wrote: > From: Jakub Kicinski <jakub.kicinski@...ronome.com> > Date: Fri, 29 Mar 2019 19:04:42 -0700 > > > This patch clears up some confusion around the meaning of bit 12 > > for FW messages related to VLAN and flower offload. > > > > Pieter says: > > It fixes issues with matching, pushing and popping vlan tags. > > We replace the vlan CFI bit with a vlan present bit that > > indicates the presence of a vlan tag. We also no longer set > > the CFI when pushing vlan tags. > > Series applied, thanks Jakub. > > Stable? It would be nice, but they will both conflict with Pablo's changes :( Especially patch 1 is quite different since Pablo merged key and mask handling into one function. The old patch would have been: @@ -65,15 +64,13 @@ nfp_flower_compile_meta_tci(struct nfp_flower_meta_tci *frame, flow_vlan = skb_flow_dissector_target(flow->dissector, FLOW_DISSECTOR_KEY_VLAN, target); /* Populate the tci field. */ + tmp_tci = NFP_FLOWER_MASK_VLAN_PRESENT; - if (flow_vlan->vlan_id || flow_vlan->vlan_priority) { - tmp_tci = FIELD_PREP(NFP_FLOWER_MASK_VLAN_PRIO, - flow_vlan->vlan_priority) | - FIELD_PREP(NFP_FLOWER_MASK_VLAN_VID, - flow_vlan->vlan_id) | - NFP_FLOWER_MASK_VLAN_CFI; - frame->tci = cpu_to_be16(tmp_tci); - } + tmp_tci |= FIELD_PREP(NFP_FLOWER_MASK_VLAN_PRIO, + flow_vlan->vlan_priority) | + FIELD_PREP(NFP_FLOWER_MASK_VLAN_VID, + flow_vlan->vlan_id); + frame->tci = cpu_to_be16(tmp_tci); } } Second conflict is just an irrelevant change in context. How would we handle this?
Powered by blists - more mailing lists