On Sat, Sep 10, 2011 at 7:24 PM, Roger Pau Monné <roger....@entel.upc.edu> wrote: > Hello, > > Thanks for the "atop" tip, now I'm able to pass the memory around, but > the kernel crashes shortly after reading the value from the returned > memory region: > > panic: kernel diagnostic assertion "uvm_page_locked_p(pg)" failed: > file "/usr/src-current/src/sys/arch/x86/x86/pmap.c", line 3215 > cpu0: Begin traceback... > copyright() at ffffffff8098aed4 > uvm_fault(0xffffffff80cbc5a0, 0x2bb13000, 1) -> e > fatal page fault in supervisor mode > trap type 6 code 0 rip ffffffff8022d887 cs e030 rflags 10246 cr2 > 2bb13a50 cpl 0 rsp ffffa0002bb130e0 > Skipping crash dump on recursive panic > panic: trap > Faulted in mid-traceback; aborting...rebooting... > > I still have to look into this (I'm going to try to mark the memory as > loked using uvm_vslock, but I'm not really sure if that is going to > help). > > 2011/9/9 Eduardo Horvath <e...@netbsd.org>: >> On Wed, 7 Sep 2011, Roger Pau Monné wrote: >> >>> Basically we use pud_request to pass the request to the user-space >>> server, and the server returns a memory address, allocated in the >>> user-space memory of it's process. Then I try to read the value of the >>> user space memory from the kernel, which works ok, I can fetch the >>> correct value. After reading the value (that is just used for >>> debugging), the physical address of the memory region is collected >>> using pmap_extract and returned. >> >> I'm not sure you can do this. The mmap() interface in drivers is designed >> to hand out unmanaged pages, not managed page frames. Userland processes >> use page frames to hold pages that could be paged out at any time. You >> could have nasty problems with wiring and reference counts. What you >> really need to do here is shared memory not a typical device mmap(). >> >> WHY do you want to do this? What is PUD? Why do you have kernel devices >> backed by userland daemons? I think a filesystem may be more appropriate >> than a device in this case. > > PUD is a framework present in NetBSD that allows to implement > character and block devices in userspace. I'm trying to implement a > blktap [1] driver purely in userspace, and the mmap operation is > needed (and it would also be beneficial for PUD to have the full set > of operations implemented, for future uses). The implementation of > blktap driver using fuse was discused in the port-xen mailing list, > but the blktap driver needs a set of specific operations over > character and block devices. > > My main concern is if it is possible to pass memory form a userspace > program to another trough the kernel (that is mainly what my mmap > implementation tries to accomplish). I trough that I could accomplish
It is called pipe(2), isn't it?
