Re: Problems with Kernel Extension on Different Mac Configurations
Re: Problems with Kernel Extension on Different Mac Configurations
- Subject: Re: Problems with Kernel Extension on Different Mac Configurations
- From: Terry Lambert <email@hidden>
- Date: Fri, 21 Sep 2007 14:28:32 -0700
On Sep 21, 2007, at 6:23 AM, JanakiRam wrote:
Hi Terry,
Let me explain my problem a bit in detail.
I'm doing maintenance of the Mac application which has User
Daemon for reporting activity and kernel extension for handling low
level file operations. This application is Creating memory in chunks
( abt 3 MB) and manages memory itself . Its also using Mach
semaphores.
i) Once my application is started ( kext as well ) , the system
hangs on PowerBook G4 , But on iMac G5 its works without any problem.
The above mentioned problem is only appearing on
PowerBook G4 but not on iMac G5. System gets hanging once i launch
my application.
This is consistently happening ?
I don't have any clue on this. Can you provide some
pointers on the reasons of such kind of behaviour ? . Do you think
this problem is related to memory management ?.
I've verified your suggestion i.e autovectorization. In
my kext XCode project this option is OFF. Still my machine is hanging.
Please help me to solve the above mentioned problem.
The reason I talked about memory issues at all is that you brought up
the issue of a MALLOC failure. But that was before this information
about your design.
Given this information, it could just as easily be that the MALLOC
failure happened because you ran it out of memory trying to buffer up
lists of events to hand off to user space before freeing the memory,
and user space is not servicing the requests as fast as they are being
generated.
User space might not service the events for a variety of reasons,
including, but not limited to, insufficient CPU power, insufficient
scheduling of the user space component, insufficient priority of the
user space component relative to the priority of other tasks on the
system which are generating events, etc..
I expect that the problem is a deadly embrace deadlock, unless you are
going out of your way to make your application and every daemon talked
to by every framework that it's linked against are immune from having
their file activity intermediated by the KEXT. Deadly embrace would
occur if it has been asked whether or not it should allow itself to
access a file, and needs to access the file in order to answer the
question about itself.
If you are not hitting a deadly embrace, and it is in fact a
starvation deadlock, it probably happens on the G4 because it has less
CPU power, and if you load the G5 up enough, it will likely happen
there too.
-
This sounds very like the announced FSEvents interface or the Common
Criteria Auditing subsystem, r the implementation of "memberd" (the
user space group membership resolver).
In all of these cases, we've had to be incredibly careful to ensure
that:
(1) Our components are immune from introspection (they don't look at
their own traffic)
(2) Except for auditing, events can be dropped "safely"
(a) for FSEvents, this means aggregating events upward in the FS
hierarchy and changing them from "this changed" to "you need to look
in all subdirectories and files of this directory to see what changed"
(b) for memberd, the operation is either blocked until a timeout
(after which it is denied), or it's just immediately denied.
(3) Events can also be "preordianed", by caching the information you
need to answer the questions about critical path requests.
(4) For auditing, if some condition prevents auditing (e.g. the audit
log fills up, etc.), the system basically locks up until the condition
is corrected (this is the right thing to do, if you need non-
repudiation).
Getting this sort of thing "right" depends very much on your goals for
your software, and you will need to understand precisely how your
software interacts with the system.
-- 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