netdev - Re: [PATCH next RFC] net: sched: mirred: move xmit to tasklet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20170418.131548.824211762596103433.davem@davemloft.net>
Date:   Tue, 18 Apr 2017 13:15:48 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     fw@...len.de
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH next RFC] net: sched: mirred: move xmit to tasklet

From: Florian Westphal <fw@...len.de>
Date: Tue, 18 Apr 2017 15:03:31 +0200

> mirred is prone to deadlocks as it invokes dev_queue_xmit while
> holding one or more qdisc locks.
> 
> Avoid lock recursions by moving tx context to a tasklet.
> 
> Signed-off-by: Florian Westphal <fw@...len.de>
> ---
>  This a stab at removing the lock recursions discussed during netconf.
> 
>  Taking the cost of the tasklet appears to be the only solution;
>  i tried to use a percpu 'history' instead but its not clear to
>  me that this avoids all corner cases.
> 
>  While this patch doesn't avoid loops we don't hang the kernel
>  anymore and removing the 'looping' filter makes things calm
>  down again (there are also other ways to create such loops anyway,
>  including use of a cable... )

The thing is, those qdisc's are per-device.

So we could return the locking cpu and back out of deadlocks just like
we do for the netdev tx lock.

Given that, maybe the remaining part of the equation could possibly be
handled by a ttl.