site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Wed, 16 Nov 2011 09:35:44 -0800 Shantonu Sen <ssen@apple.com> 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com