License issue #213
Comments
|
I think that preference is only intended for Rust official projects. After all, anybody can licence their own projects however they wish (assuming by ecosystem you mean the Rust one, i.e. crates.io etc.). In any case, if we end up with a custom Nevertheless, even if the code ends up being only useful for the Linux kernel, parts of the code could still be useful for others, so the question still applies. Another point is that we may reuse/share some parts from |
|
It's a requirement only for Rust official projects, but all libraries in the Rust ecosystem are encouraged to adopt MIT and Apache dual license, see https://rust-lang.github.io/api-guidelines/necessities.html#crate-and-its-dependencies-have-a-permissive-license-c-permissive. |
|
Many parts of the kernel are dual licensed, e.g. |
|
@ojeda sorry to hijack the thread with a question but is there a plan or work being done on the |
My reading of that document is different. It talks about libraries that need the compatibility, not all of them. For instance, if you write a library that you would like to be used by |
Thanks! I would recommend that you join the meetings in that case. (Also, for general questions like this, please use the mailing list. The relevant issue is #199.) |
When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below. [..... other info removed for brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING: possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [ 82.890906] -------------------------------------------- [ 82.890906] ping/418 is trying to acquire lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] but task is already holding lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] other info that might help us debug this: [ 82.890906] Possible unsafe locking scenario: [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906] lock(&sch->q.lock); [ 82.890906] lock(&sch->q.lock); [ 82.890906] [ 82.890906] *** DEADLOCK *** [ 82.890906] [..... other info removed for brevity....] Example setup (eth0->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0 Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1 tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0 We fix this by adding an owner field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time, if the qdisc owner is the same CPU, the packet is dropped to break the loop. Reported-by: Mingshuai Ren <renmingshuai@huawei.com> Closes: https://lore.kernel.org/netdev/20240314111713.5979-1-renmingshuai@huawei.com/ Fixes: 3bcb846 ("net: get rid of spin_trylock() in net_tx_action()") Fixes: e578d9c ("net: sched: use counter to break reclassify loops") Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Victor Nogueira <victor@mojatatu.com> Reviewed-by: Pedro Tammela <pctammela@mojatatu.com> Tested-by: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://lore.kernel.org/r/20240415210728.36949-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The ecosystem prefers MIT + Apache 2.0 dual licensing while Linux is GPL-2.0. Linux-related would certainly be GPL-2.0, but at the same time Rust-for-linux may produce some libraries (e.g. fallible alloc) that are useful for other libraries as well, and license them in GPL-2.0 may hinder adoption and can potentially split the ecosystem as it cannot be merged back upstream.
Would it make sense to have a policy on which parts could be licensed in MIT + Apache 2.0 (I envision the fallible alloc fork be licensed this way)?
The text was updated successfully, but these errors were encountered: