Re: kern/51412: Syscall I/O race condition leads to deadlock and lost interrupts

[David Holland <dholland-bugs%netbsd.org@localhost>]

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

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/51412: Syscall I/O race condition leads to deadlock and
 lost interrupts
Date: Mon, 5 Sep 2016 18:53:03 +0000

 On Sun, Aug 28, 2016 at 05:00:01PM +0000, Ryan Brackenbury wrote:
  >   >What are "kernel parameters"? Are you talking just about envstat? Or
  >   >sysctl? Or the combination of the two? Or...?
  >
  >  My experience here comes from a sysadmin/hobbyist (not kern hacker)
  >  perspective, so I might be using the wrong terminology.
 
 That's fine -- just need to be clear what we're talking about.
 
  >  I am referring to
  >  the kernel values and variables set/retrieved via ioctls from sysctl and
  >  envstat - such as those in the MIB for sysctl. I am not sure how sysctl and
  >  envstat vary about how they both interact with the kernel, so I can't
  >  pretend to have a more in-depth understanding than that above.
 
 They're quite different systems and it's strange that they should be
 coupled in this way. (though, given the code behind envstat, maybe
 it's not that surprising...)
 
  >  What I do know is that using one and/or the other command can influence the
  >  execution of the other. For example: if retrieving values with envstat
  >  deadlocks on I/O, calling sysctl can be enough to unblock envstat (and vice
  >  versa). In my experience, also running either program concurrent with
  >  another copy of the same has caused these I/O blocks. So to answer your
  >  question - either envstat, or sysctl, or a combination of the two is
  >  sufficient.
 
 This is odd, but we'll certainly look into it.
 
  >  > Those aren't zombies; zombies have state 'Z'.
  >
  >  Yes; it just seemed like an appropriate way to compare them, since they
  >  were un-killable but still using up system resources.
 
 Right, it's just confusing to reuse a technical term with a different
 specific meaning :-)
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost