+82
−20
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
The bridge core assumes that enabling/disabling vlan_filtering will translate into the simple toggling of a flag for switchdev drivers. That is clearly not the case for sja1105, which alters the VLAN table and the pvids in order to obtain port separation in standalone mode. There are 2 parts to the issue. First, tag_8021q changes the pvid to a unique per-port rx_vid for frame identification. But we need to disable tag_8021q when vlan_filtering kicks in, and at that point, the VLAN configured as pvid will have to be removed from the filtering table of the ports. With an invalid pvid, the ports will drop all traffic. Since the bridge will not call any vlan operation through switchdev after enabling vlan_filtering, we need to ensure we're in a functional state ourselves. Hence read the pvid that the bridge is aware of, and program that into our ports. Secondly, tag_8021q uses the 1024-3071 range privately in vlan_filtering=0 mode. Had the user installed one of these VLANs during a previous vlan_filtering=1 session, then upon the next tag_8021q cleanup for vlan_filtering to kick in again, VLANs in that range will get deleted unconditionally, hence breaking user expectation. So when deleting the VLANs, check if the bridge had knowledge about them, and if it did, re-apply the settings. Wrap this logic inside a dsa_8021q_vid_apply helper function to reduce code duplication. Signed-off-by:Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
CRA Git | Maintained and supported by SUSTech CRA and CCSE