Re: kern/53043: deadlock on evbarm/TEGRA with netbsd-8

[Nick Hudson <skrll%netbsd.org@localhost>]

The following reply was made to PR kern/53043; it has been noted by GNATS.

From: Nick Hudson <skrll%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost, ozaki-r%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost, skrll%netbsd.org@localhost
Cc: 
Subject: Re: kern/53043: deadlock on evbarm/TEGRA with netbsd-8
Date: Thu, 22 Feb 2018 20:59:22 +0000

 On 02/22/18 08:25, Ryota Ozaki wrote:
 > The following reply was made to PR kern/53043; it has been noted by GNATS.
 >
 > From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
 > To: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%netbsd.org@localhost>
 > Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
 > Subject: Re: kern/53043: deadlock on evbarm/TEGRA with netbsd-8
 > Date: Thu, 22 Feb 2018 17:24:13 +0900
 >
 >   This is a deadlock that occurs between softnet_lock and IFNET_LOCK;
 >   the locks can be held in different orders.
 >   
 >   softnet_lock in in6_control (and in_control) had been introduced to
 >   address PR 51356 that was a race condition between ioctls and packet
 >   inputs and forwarding (ipintr and ip6intr). However holding it
 >   in6_control and in_control was not a good idea because softnet_lock
 >   should be basically held at the very beginning of call paths to comply
 >   the locking order and the functions were in the middle of call paths.
 >   
 >   I think we have two options to solve the issue:
 >   (1) Give up relying on softnet_lock to protect the network stack and
 >       remove softnet_lock from in6_control/in_control and add some
 >       KERNEL_LOCK to the network stack, e.g., ipintr and ip6intr.
 >   (2) Just get rid of softnet_lock from in6_control/in_control.
 >   
 >   (1) is safer than (2) but add some performance penalty. (2) sounds
 >   awful but the situation is the same as netbsd-7 and netbsd-6, i.e.,
 >   it's enough safe in practice...
 >   
 >   A patch for (1) is here: http://www.netbsd.org/~ozaki-r/fix-pr53043.diff
 >   
 >   Note that I gave up moving softnet_lock to doifioctl because it
 >   just introduced other deadlocks and was more problematic.
 >   
 >   Comments?
 >   
 
 I think 1) is the only real option for now. Hopefully someone can 
 address finer grained locking soon.
 
 I tested your patch and my tegra can now complete an atf-run.
 
 Thanks,
 Nick