Re: sysctl spinning (was: Re: ps Causes Hard Hang)

On Wed, 3 Mar 2004, Robert Watson wrote:

> On Wed, 3 Mar 2004, Cy Schubert wrote:
>
> > I'm running 5 -CURRENT systems. My firewall system, using IPF, hard
> > hangs every time ps is entered -- totally unresponsive, requiring either
> > a power cycle or reset switch to bring it back to life.
>
> Alan Cox and I have both experienced this -- it's actually only a hard
> hang if you're trying to use the syscons break to debugger, serial break
> to debugger can get into DDB fine.  It looks like the sysctl code is
> spinning in kernel, possibly due to looping waiting for a response other
> than EAGAIN.  I'm wonder if it was the recent limits on locked memory
> changes in sysctl, although at first we thought it might be the sleepq
> changes (seems less likely now).  Because sysctl holds Giant, the other
> CPUs are locked out of Giant-protected bits of the kernel (many of them),
> including Syscons.

It also holds sysctllock, but should possibly drop both for loops like
this.  Such loops should be harmless on preemptible kernels.  Processes
doing them should be preemptible and scheduled in the usual way (and
killable).  However, holding Giant prevents preemption except by
INTR_MPSAFE interrupt handlers (and userland CPU hogs?).

I plan to fix not-so-similar loops in vn_rdwr_inchunks() (callers of)
uiomove() by just dropping Giant.  These loops already drop Giant in
uio_yield(), but calling uio_yield() shouldn't be needed on preemptible
kernels, and the calls in uiomove() no longer work properly (switchticks
is reset on every context switch and context switches happen too often
to pessimize interrupt handling, so switchticks can only grow to hogticks
in exceptional cases).

Bruce