miscfs/specfs/spec_vnops.c panic (triggered by filemon(4))

[Paul Goyette <paul%whooppee.com@localhost>]

Looking into another problem (with filemon(4) if it matters), I ran into 
the following DIAGNOSTIC code in miscfs/specfs/spec_vnops.c:

#ifdef DIAGNOSTIC
        if (uio->uio_rw != UIO_WRITE)
                panic("spec_write mode");
> > >     if (&uio->uio_vmspace->vm_map != kernel_map &&
> > >         uio->uio_vmspace != curproc->p_vmspace)
                panic("spec_write proc");
#endif

There is some code in dev/filemon/filemon.c that initializes a struct 
uio by calling

	uio_setup_sysspace(&auio);

(Based on the function name, one would assume that the struct uio would 
be set up for transfers to kernel address space rather than a process's 
user address space.)

uio_setup_sysspace() calls

	uio->uio_vmspace = vmspace_kernel();

which in turn is defined (in sys/proc.h) as

	#define    vmspace_kernel()        (proc0.p_vmspace)

proc0.p_vmspace is initialized (in kern/kern_proc.h) to

	.p_vmspace = &vmspace0

and vmspace0 is initialized by uvmspace_init().


Immediately upon return from uio_setup_sysspace(), I printed the values:

	filemon_output: &auio->uio_vmspace->vm_map 0xffffffff805e3120
	filemon_output: kernel_map                 0xffffffff805dea80

Clearly, these are different values, and thus will trigger the panic in 
spec_vnops.c unless we happen to get lucky and the uio just happens to 
reference curproc!

Note: from the kernel map, 0xffffffff805e3120 is the address of 
vmspace0, as would be expected from the above initialization code.  The 
map doesn't have anything that corresponds to 0xffffffff805dea80 - the 
closest items are

                0xffffffff805ddd70                kmembase
 .bss           0xffffffff805deba0       0x70 uvm_loan.o


So, I see the following possible sources of trouble here (in increasing 
order of likelihood?):

1. uio_setup_sysspace() is wrong

   This is somewhat unlikely, since it is used (via the macro
   UIO_SETUP_SYSSPACE) in many other places in the system

2. the DIAGNOSTIC check code is wrong, or

3. (most likely!) filemon(4)'s usage of uio_setup_sysspace() is wrong.

4. Something else?

Whichever is wrong, it would be good to fix.


FWIW, it seems that specfs is the only place where these particular 
checks are being made.  None of the other specfs or ufs file systems 
appear to make checks similar to "spec_write proc".  filemon(4) works 
fine when the "events" are written to a normal file;  it fails when 
asked to write to (for example) STDOUT_FILENO.  :)





+------------------+--------------------------+------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+