| Hi Sheetal,
It specifically warns us to be very careful when the UID of the VFS thread is owned by root: IE kauth_cred_getuid (KAuthCred) == 0 because you have a serious risk of deadlock. Basically, if you need to handle events as root, it is almost impossible to call user-space.
This is why I hope Apple will officially support PID testing (or something better EG progress group, mach task, BSD SID, Security Session ID,...) as well as UID & GID testing at some stage in the future, so that it's easier to avoid the deadlock. This also means doing something about AIO kernel threads, because these are indistinguishable from other kernel threads. (They all have no PID, or if they do, it's 0)....and while they're at it, supporting kevent(2) for AIO could be fixed at the same time. Here's hoping!...
In your case, I'd preallocate some wired (non-pageable) memory for your listener to use when it's invoked as root. Most of the time, you won't be invoked by root so you can call IOMalloc(). Using these together will obviate the need to preallocate so much wired memory, which is undesirable as it raises the minimum physical RAM requirement for your application. Likewise, you need to synchronise using a spin lock when invoked by root, otherwise use a mutex, which will allow you to block your thread most of the time, freeing up the CPU core most of the time. Of course, blocking a VFS thread for a long time is a bad idea anyway as you'll slow down I/O.
Good luck!
On 29 Nov 2011, at 4:12 am, sheetal phirke wrote:
Hi,
We need to monitor root 's I/O events & allocate memory in listener as well. Is it not feasible? What care should be taken?
Thanks & Regards, Sheetal
From: Christopher James Elphinstone Chandler <email@hidden>
To: email@hidden
Sent: Wednesday, 23 November 2011 2:45 AM
Subject: Re: IOMalloc / IOFree while holding a mutex
Hi All,
On 21 Nov 2011, at 06:03, sheetal phirke wrote:
> I am writing IOKit driver with Vnode & File listener.
> Is it safe for me to take mutex lock while IOMalloc / IOFree?
I think that would be a very bad idea. Listeners in the vnode scope are potentially on the page out path (because the pager might need to create a new swap file), which makes allocating memory in your code potentially dangerous, regardless of whether you're holding a mutex or not.
Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
For the KAuth callback
static int VNodeListener ( kauth_cred_t KAuthCred, void * pvData, kauth_action_t KAuthAction, uintptr_t puiArg0, uintptr_t puiArg1, uintptr_t puiArg2, uintptr_t puiArg3 );
surely this is only true if kauth_cred_getuid
(KAuthCred) == 0?
In this case, the KAuth VNode callback has been called for a VFS thread owned by root, because the VNode pager (dynamic_pager) and all asynchronous I/O (AIO) kernel threads run as root. So a simple check at the start of the callback for a root-owned thread can prevent this problem. (The KAuth technical note advises strongly in favour of this anyway to prevent deadlock with other system daemons.) Of course this means that you can't
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
|