On Sat, Jan 18, 2014 at 02:06:05AM +0100, Samuel Thibault wrote: > Diego Nieto Cid, le Fri 17 Jan 2014 22:49:25 -0200, a écrit : > > El ene 17, 2014 11:36 a.m., "Marin Ramesa" <m...@hi.t-com.hr> escribió: > > > + > > > +kern_return_t > > > +futex_wait(task_t task, vm_offset_t futex_address, int value, > > > + mach_msg_timeout_t msec, boolean_t private_futex) > > > +{ > > > + if (private_futex) { > > > + struct private_futex *futex; > > > + > > > + futex = futex_private_lookup_address(futex_address); > > > + if (futex == NULL) { > > > + futex = futex_private_init(futex_address); > > > + if (futex == NULL) > > > + return KERN_RESOURCE_SHORTAGE; > > > + } > > > + > > > + if (__atomic_load_n( > > > + (int *) futex_address, __ATOMIC_RELAXED) == > > > value) { > > > > Are you sure you can dereference futex_address? > > > > It's a user supplied virtual address which is probably not valid in the > > kernel's virtual address space (unless things like copyin are used) > > > > I have the vague idea that the kernel has it's own address space. Can > > somebody > > confirm that? :-) > > Yes. Care has to be taken when dereferencing user pointers.
This is why I was insisting on passing *memory* through IPC. But this does work in most cases on i386 since the kernel page tables are shared by all user page tables to avoid a complete TLB flush on kernel entry, as it's done for practically every system. So in practice, setting some user data and accessing it from the kernel soon after will succeed most of the time because writing the content will cause page faults if needed, after which the kernel can simply read it. That is how e.g. mach_print is able to do its job, although, for this special call, it was done on purpose to avoid the VM system (since it's a debugging call). -- Richard Braun