summaryrefslogtreecommitdiff
path: root/fs/f2fs/xattr.c
diff options
context:
space:
mode:
authorVladimir Oltean <vladimir.oltean@nxp.com>2023-07-01 01:20:10 +0300
committerDavid S. Miller <davem@davemloft.net>2023-07-03 09:12:30 +0100
commita398b9ea0c3b791b7a0f4c6029a62cf628f97f22 (patch)
treed29ccd92f96df0aae7eeb07731ac62f9c3a8e857 /fs/f2fs/xattr.c
parent6ca3c005d0604e8d2b439366e3923ea58db99641 (diff)
net: dsa: tag_sja1105: fix source port decoding in vlan_filtering=0 bridge mode
There was a regression introduced by the blamed commit, where pinging to a VLAN-unaware bridge would fail with the repeated message "Couldn't decode source port" coming from the tagging protocol driver. When receiving packets with a bridge_vid as determined by dsa_tag_8021q_bridge_join(), dsa_8021q_rcv() will decode: - source_port = 0 (which isn't really valid, more like "don't know") - switch_id = 0 (which isn't really valid, more like "don't know") - vbid = value in range 1-7 Since the blamed patch has reversed the order of the checks, we are now going to believe that source_port != -1 and switch_id != -1, so they're valid, but they aren't. The minimal solution to the problem is to only populate source_port and switch_id with what dsa_8021q_rcv() came up with, if the vbid is zero, i.e. the source port information is trustworthy. Fixes: c1ae02d87689 ("net: dsa: tag_sja1105: always prefer source port information from INCL_SRCPT") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'fs/f2fs/xattr.c')
0 files changed, 0 insertions, 0 deletions