> From: Neil Horman
> The team driver still seems
> to be an outlier there though I think , in that it doesn't guarantee the
> holding
> of rtnl in its port add/delete paths.
Not seeing where this is the case in the team driver today? They were actually
calling __netpoll_cleanup synchronously
On Thu, Oct 18, 2018 at 03:17:06PM +, Banerjee, Debabrata wrote:
> > From: Neil Horman
>
> > Agreed, this doesn't make sense. If you want a synchronous cleanup, create
> > a wrapper function that creates a wait queue, calls __netpoll_free_async,
> > and blocks on the wait queue completion.
> From: Neil Horman
> Agreed, this doesn't make sense. If you want a synchronous cleanup, create
> a wrapper function that creates a wait queue, calls __netpoll_free_async,
> and blocks on the wait queue completion. Modify the cleanup_work
> method(s) to complete the wait queue, and you've got
On Wed, Oct 17, 2018 at 09:47:05PM -0700, David Miller wrote:
> From: Debabrata Banerjee
> Date: Fri, 12 Oct 2018 12:59:29 -0400
>
> > @@ -826,7 +826,10 @@ static void netpoll_async_cleanup(struct work_struct
> > *work)
> >
> > void __netpoll_free_async(struct netpoll *np)
> > {
> > - sche
From: Debabrata Banerjee
Date: Fri, 12 Oct 2018 12:59:29 -0400
> @@ -826,7 +826,10 @@ static void netpoll_async_cleanup(struct work_struct
> *work)
>
> void __netpoll_free_async(struct netpoll *np)
> {
> - schedule_work(&np->cleanup_work);
> + if (rtnl_is_locked())
> + __
This fixes a problem introduced by:
commit 2cde6acd49da ("netpoll: Fix __netpoll_rcu_free so that it can hold the
rtnl lock")
When using netconsole on a bond, __netpoll_cleanup can asynchronously
recurse multiple times, each __netpoll_free_async call can result in
more __netpoll_free_async's. Thi
Actually I realized this patch might be problematic, although someone might be
holding rtnl, it might not be the current callstack. A different solution is
needed I think. Input appreciated.
-Deb
