+8
−8
+9
−16
+10
−14
+3
−0
+0
−14
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
Vladislav Yasevich says: ==================== Restore UFO support to virtio_net devices commit 3d0ad094 Author: Ben Hutchings <ben@decadent.org.uk> Date: Thu Oct 30 18:27:12 2014 +0000 drivers/net: Disable UFO through virtio Turned off UFO support to virtio-net based devices due to issues with IPv6 fragment id generation for UFO packets. The issue was that IPv6 UFO/GSO implementation expects the fragment id to be supplied in skb_shinfo(). However, for packets generated by the VMs, the fragment id is not supplied which causes all IPv6 fragments to have the id of 0. The problem is that turning off UFO support on tap/macvtap as well as virtio devices caused issues with migrations. Migrations would fail when moving a vm from a kernel supporting expecting UFO to work to the newer kernels that disabled UFO. This series provides a partial solution to address the migration issue. The series allows us to track whether skb_shinfo()->ip6_frag_id has been set by treating value of 0 as unset. This lets GSO code to generate fragment ids if they are necessary (ex: packet was generated by VM or packet socket). Since v3: - Resolved build issue when IPv6 is a module. - Removed trailing white space. Since v2: - Rebase and rebuild to make sure everything works. No changes to the patches were done. Since v1: - Removed the skb bit and use value of 0 as tracker. - Used Eric's suggestion to set fragment id as 0x80000000 if id generation procedure yeilded a 0 result. - Consolidated ipv6 id genration code. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
CRA Git | Maintained and supported by SUSTech CRA and CCSE