In article <m2n.s.12cRqD-001OSQ@chiark.greenend.org.uk> you write:
>I have run into some problems with mmap on /dev/kmem (we're
>running NetBSD-1.4.1/arm32). 
>
>Description of the problem;
>
>A user level applications retreives a kernel address, maps
>it into its address space with `mmap' (write-able).   It then
>modifies some of the data and does a `ioctrl' into our driver
>that checks the data. Sometimes the data is beeing modifies
>when switching from user to kernel address space. It seems
>that the data is put on the free list or something . If you
>examin the data, it has the following pattern;
>
>0       4        8        12
>ADDRESS deadbeef deadbeef deadbeef ...
>
>This never happens when we run on NetBSD-1.4.1/i386.

From sys/arch/arm32/arm32/mem.c (and most other mem.cs, I expect):

--------8<--------
int
mmmmap(dev, off, prot)
        dev_t dev;
        int off, prot;
{
        struct proc *p = curproc;       /* XXX */

        /*
         * /dev/mem is the only one that makes sense through this
         * interface.  For /dev/kmem any physaddr we return here
         * could be transient and hence incorrect or invalid at
         * a later time.  /dev/null just doesn't make any sense
         * and /dev/zero is a hack that is handled via the default
         * pager in mmap().
         */
-------->8--------

If mmap() on /dev/kmem isn't returning an error, I think something is wrong.

-- 
Ben Harris