From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752627AbdLHDLW (ORCPT ); Thu, 7 Dec 2017 22:11:22 -0500 Received: from mail-pg0-f65.google.com ([74.125.83.65]:39502 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751904AbdLHDLU (ORCPT ); Thu, 7 Dec 2017 22:11:20 -0500 X-Google-Smtp-Source: AGs4zMZ7hmfo+PHMz5bwCJkEIXqIPjqJ//vh0EKWgnCnBK3C0efuayWK+m/edWghJJcPg8/O4LS1nQ== Message-ID: <1512702678.25033.20.camel@gmail.com> Subject: Re: [PATCH net-next] tuntap: fix possible deadlock when fail to register netdev From: Eric Dumazet To: Jason Wang , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: mst@redhat.com, Willem de Bruijn Date: Thu, 07 Dec 2017 19:11:18 -0800 In-Reply-To: <1512701655-18751-1-git-send-email-jasowang@redhat.com> References: <1512701655-18751-1-git-send-email-jasowang@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2017-12-08 at 10:54 +0800, Jason Wang wrote: > Private destructor could be called when register_netdev() fail with > rtnl lock held. This will lead deadlock in tun_free_netdev() who > tries > to hold rtnl_lock. Fixing this by switching to use spinlock to > synchronize. > > Fixes: 96f84061620c ("tun: add eBPF based queue selection method") > Reported-by: Eric Dumazet > Cc: Eric Dumazet > Cc: Willem de Bruijn > Signed-off-by: Jason Wang > --- >  drivers/net/tun.c | 7 ++++--- >  1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > index 787cc35..f7ccd79 100644 > --- a/drivers/net/tun.c > +++ b/drivers/net/tun.c > @@ -2050,8 +2050,11 @@ static int __tun_set_steering_ebpf(struct > tun_struct *tun, >   new->prog = prog; >   } >   > - old = rtnl_dereference(tun->steering_prog); > + spin_lock(&tun->lock); > + old = rcu_dereference_protected(tun->steering_prog, > + lock_is_held(&tun->lock)); >   rcu_assign_pointer(tun->steering_prog, new); > + spin_unlock(&tun->lock); > Hi Jason, thank you for the following up. Have you tested this code path with lockdep enabled ? My gut feeling is that you need spin_lock_bh() here. Thanks