+2
−2
+3
−3
+10
−4
+172
−98
+6
−3
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
Florian Westphal says: ==================== rtnetlink: rework handler (un)registering Peter Zijlstra reported (referring to commit 019a3169, "rtnetlink: add reference counting to prevent module unload while dump is in progress"): 1) it not in fact a refcount, so using refcount_t is silly 2) there is a distinct lack of memory barriers, so we can easily observe the decrement while the msg_handler is still in progress. 3) waiting with a schedule()/yield() loop is complete crap and subject life-locks, imagine doing that rtnl_unregister_all() from a RT task. In ancient times rtnetlink exposed a statically-sized table with preset doit/dumpit handlers to be called for a protocol/type pair. Later the rtnl_register interface was added and the table was allocated on demand. Eventually these were also used by modules. Problem is that nothing prevents module unload while a netlink dump is in progress. netlink dumps can be span multiple recv calls and netlink core saves the to-be-repeated dumper address for later invocation. To prevent rmmod the netlink core expects callers to pass in the owning module so a reference can be taken. So far rtnetlink wasn't doing this, add new interface to pass THIS_MODULE. Moreover, when converting parts of the rtnetlink handling to rcu this code gained way too many READ_ONCE spots, remove them and the extra refcounting. Take a module reference when running dumpit and doit callbacks and never alter content of rtnl_link structures after they have been published via rcu_assign_pointer. Based partially on earlier patch from Peter. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
CRA Git | Maintained and supported by SUSTech CRA and CCSE