NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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 <>
To: "" <>
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: Note that I gave up moving softnet_lock to doifioctl because it
  just introduced other deadlocks and was more problematic.

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.


Home | Main Index | Thread Index | Old Index