Re: IOMalloc / IOFree while holding a mutex
Re: IOMalloc / IOFree while holding a mutex
- Subject: Re: IOMalloc / IOFree while holding a mutex
- From: chas williams - CONTRACTOR <email@hidden>
- Date: Thu, 17 Nov 2011 10:16:08 -0500
On Wed, 16 Nov 2011 09:35:44 -0800
Shantonu Sen <email@hidden> wrote:
> There's some layers of sublety here. You can do a lot of things at a technical
>level. Certainly there are no assertions or consistency checks that
>prevent you from holding an IOLock/lck_mtx_t. However if you are
>writing a storage driver that is on the paging path, consider what
>happens if you take the lock (or run under a command gate), attempt the
>IOMalloc, which in turn needs to free up pages by paging out user data,
>which issues an I/O, which tries to acquire the mutex previously
>acquired? You can try to massage the code to accept an asyncReadWrite()
>without taking any locks, so you don't end up deadlocking, but it
>requires some thought. This is one of the reasons why memory
>allocations on the I/O path is frowned upon.
as a side note, you should be able to avoid this (aleast for an
IOSCSIParallelInterfaceController) by using ReportHBASpecificTaskDataSize
and GetHBADataPointer. atleast i gather that is why these members
exist -- to avoid this situation described above.
_______________________________________________
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