cvs commit: src/sys/kern vfs_subr.c

[Bruce Evans]

On Mon, 12 May 2003, Robert Watson wrote:

> rwatson     2003/05/12 07:37:47 PDT
>
>   FreeBSD src repository
>
>   Modified files:
>     sys/kern             vfs_subr.c
>   Log:
>   Remove bogus locking from DDB's "show lockedvnods" command: using
>   synchronization primitives from inside DDB is generally a bad idea,
>   and in this case it frequently results in panics due to DDB commands
>   being executed from the sio fast interrupt context on a serial
>   console.  Replace the locking with a note that a lack of locking
>   means that DDB may get see inconsistent views of the mount and vnode
>   lists, which could also result in a panic.  More frequently,
>   though, this avoids a panic than causes it.

ddb may see inconsistent views, but this is not due to its lack of locking.
ddb locks everything, so it sees precisely the current view of everything.
It is fundamental that this view might not be consistent, since ddb can't
obey normal locking semantics.

Using ddb commands fast interrupt context just increases the chance of
freezing the system in an inconsistent state.  Stopping at ordinary
breakpoints gives the same problem if the breakpoints are in critical
code.  Stopping at a breakpoint in code that is changing the state to
be consistent ensures seeing an inconsistent state.

Inconsistencies seen by ddb commands shouldn't result in panics unless
there are bugs in the commands.  ddb commands should do little more
than read memory and print the result using db_printf().  If they
follow a garbage pointer, then the fault for this is handled and control
is returned to ddb using longjmp().  (The fault is actually slightly
mishandled by complaining about it in trap() using printf() before giving
ddb a chance to catch it.)

Calling locking functions from this command was one of the bugs in it.
Remaining bugs include:
- the command begins with a printf().  ddb commands must use db_printf().
- VOP_ISLOCKED() is called, so the command inherits any bugs from this
  function not being ddb-aware.  Perhaps there are none, but this is hard
  to see.
- vprintf() is called, so the command inherits all bugs from this function
  not being ddb-aware.  vprint() begins with a printf()...

Bruce