Re: dtrace return hook missing for some iokit funcs?
Re: dtrace return hook missing for some iokit funcs?
- Subject: Re: dtrace return hook missing for some iokit funcs?
- From: Terry Lambert <email@hidden>
- Date: Thu, 22 Apr 2010 14:18:26 -0700
On Apr 22, 2010, at 8:05 AM, Andrew Gallatin wrote:
Terry Lambert wrote:
It's an optimization issue; the code results in a tail call to
makeMapping(), and it misses the return (basically, because there
isn't one). If you failed to get a memory mapping via new
IOMemoryMap, it also does this.
There are three ways this function can fail:
(1) the new fails (you are out of kernel memory)
(2) the mapping->init() fails; generally because the parameters
are out of range
(3) the makeMapping() fails; generally because the task you were
trying to map it into is no more
I'm in the context of spec_iotcl from that task, so I think that's
not the problem.
Not necessarily. Just because you are in a thread belonging to the
task does not mean that the task itself (and its address space) have
not been externally terminated by a third party, or by another thread
within the task, or by the task throwing an exception resulting in
termination.
If you compile a DEBUG kernel, you will get an IOLog telling you
more or less exactly what's going on.
You can also dtrace the tail-called function return value for the
functions involved, which would also get you the result code.
The weird thing is that sometimes it "works". When it does, the
process
bus-errors on access to the mapped memory. If coredumps are enabled,
the kernel then panics when trying to write the core file. :(
I may have to resort to a debug kernel. I'm sure I've botched
something
simple, but I'm not sure what. Due to some core code in the shared
part of the driver changing, I've had to go from mapping out
one chunk of kernel memory to mapping out a bunch of page-sized
page aligned chunks. So my code has gone from:
md = IOMemoryDescriptor::withAddress(kva, len, kIODirectionOutIn);
to
md = IOMemoryDescriptor::withAddressRanges(range, num_pages,
kIODirectionOutIn,
kernel_task);
With suitable code to prepare IOAddressRange range, one for
each page in the range.
One interesting bit is that each page already has a prepared()
memory descriptor. However, I (think I) need to create a new
memory descriptor to use to map them into the application
virtually contiguously. Would having 2 MDs covering the same
region of memory cause an issue?
Not to my knowledge, since this is easily possible with mmap(). You
could be running out of the ability to map, though, if you are mapping
enough discrete pages, since mapping regions are a (relatively) scarce
resource. I'm by no means the expert on the code path, I just
answered because this was related to a peculiarity of dtrace on x86
architecture.
Maybe someone else can answer the question for you.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden