Re: Kernel Panic while trying to access the datastructure parameter in ioctl call.
Re: Kernel Panic while trying to access the datastructure parameter in ioctl call.
- Subject: Re: Kernel Panic while trying to access the datastructure parameter in ioctl call.
- From: JanakiRam <email@hidden>
- Date: Fri, 20 Jul 2007 00:48:26 +0530
Hi Lambert,
Thanks for the Quick response. Let me provide some more information about the System hang/panic
1) You could still have failed to include 'W' in the _IO
declaration, which means the data never made it in from user space,
and the only thing in the buffer is stack garbage.
I've included the W and R as well. It is _IOWR('s', 1, IOCTL_Struct_t).But still its reproducing.
2) use a #pragma or __attribute__ to pack your structure), then the
structure you are dereferencing may not have it's fields aligned with
the structure that user space filled out. So the field you think you
are getting may be overlaid with some other field(s) in the structure,
and you are getting garbage.
I'm using same header file which has the structure and even after applying the __attribute__ to structure its hanging/panicking.
3) If you fill out a bogus pointer in the structure in user space,
then the area you are attempting to copy in may in fact be garbage or
not in the user address space; this should not result in a panic,
however, and what should happen is EFAULT (or in the case of
copyinstr, perhaps ENAMETOOLONG, if there is no NULL termination.
I'm passing a proper reference. But still its reproducing.
4) The most likely cause is that your length is bogus; I notice that
your buffer "data" (which should not be a stack buffer, it should be
allocated!) is 2K in size, but you don't do anything to ensure that
your count "bytes" is > 0 and less than 2K, so you could easily be
overflowing the buffer. Another possibility is that, since 2K is a
heck of a lot of data in kernel terms (1/8th of your entire available
stack!!!), you could be trashing the kernel stack, resulting in the
panic (this is less likely than simply having a bogus length and
smashing your own stack, but it's a possibility).
Is this a restriction that we can't send the data more than 2k from user space to kernel space ? . If we need to send more data from user space to general kext , pls suggest ways to do it.
Even after putting the > 0 && < 2k cindition , its still reproducing.
5) Finally, if you are using a worker thread to do the work instead
of doing it in the context of the process making the call (you should
know whether or not you are using one - in fact, you should have told
us this when you asked the question...), then it's trying to copy in
from kernel_process, which is the wrong process to copy in from.
Basically, all copies in or out MUST occur in the context of the
process requesting the copy.
I've a user space daemon process which gets created from the main program using pthreads. From User space daemon process i'm calling the ioctl to kernel extension. Do you mean this way of doing it is not the proper way ?
Please provide your views on this.
Thanks in Advacne.
-JanakiRam.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden