From: Daniel Borkmann
Date: Wed, 20 May 2015 17:13:33 +0200
> Vijay reported that a loop as simple as ...
...
> ... will panic the kernel. Moreover, he bisected the change
> apparently introducing it to 78fd1d0ab072 ("netlink: Re-add
> locking to netlink_lookup() and seq walker").
>
> The remov
On Wed, 2015-05-20 at 20:12 +0200, Daniel Borkmann wrote:
> Effectively, every in-tree classifier (rsvp is the only exception)
> is making use of call_rcu(). Moreover, moving this into every
> ->destroy() handler would also be unnecessary overhead, imho, as
> this is only relevant when we actually
On 5/20/15 11:12 AM, Daniel Borkmann wrote:
Effectively, every in-tree classifier (rsvp is the only exception)
is making use of call_rcu(). Moreover, moving this into every
->destroy() handler would also be unnecessary overhead, imho, as
this is only relevant when we actually _unload_ a module.
On Wed, May 20, 2015 at 11:12 AM, Daniel Borkmann wrote:
> On 05/20/2015 07:38 PM, Cong Wang wrote:
> ...
>>
>> Why synchronize_rcu() even matters here? It waits for
>> readers, not for RCU callbacks.
>
>
> Hm, I am mentioning it here as it was related to 78fd1d0ab072
> as explained in the commit
On 05/20/2015 07:38 PM, Cong Wang wrote:
...
Why synchronize_rcu() even matters here? It waits for
readers, not for RCU callbacks.
Hm, I am mentioning it here as it was related to 78fd1d0ab072
as explained in the commit message.
Since we came here via unregister_tcf_proto_ops(), there
are no
> Vijay, can you give this a run on your side? This fixes the panic
> on my side, thanks!
Thanks for the explanation and patch Daniel !
Yes. This also fixes the crash for me. So,
Tested-by: Vijay Subramanian
Vijay
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the bod
On Wed, May 20, 2015 at 8:13 AM, Daniel Borkmann wrote:
> Vijay reported that a loop as simple as ...
>
> while true; do
> tc qdisc add dev foo root handle 1: prio
> tc filter add dev foo parent 1: u32 match u32 0 0 flowid 1
> tc qdisc del dev foo root
> rmmod cls_u32
> done
>
Vijay reported that a loop as simple as ...
while true; do
tc qdisc add dev foo root handle 1: prio
tc filter add dev foo parent 1: u32 match u32 0 0 flowid 1
tc qdisc del dev foo root
rmmod cls_u32
done
... will panic the kernel. Moreover, he bisected the change
apparently i
