Joachim Worringen wrote:
> Greetings,
>
> I need to copy data from kernel to user space and vice versa; naturally, 
> this should happen as fast as possible, and page faults may occur.
>
> Looking at the man pages of ddi_copyin()/ddi_copyout(), it says:
> "
>       Driver defined locks should not be held across calls to this
>       function.
> "
>
> uiomove(9F) can be used for the same purpose (some more setup overhead), 
> but the man page does not mention locks at all.
>
> Thus, I wonder which problems can occur if holding a driver-defined lock 
> while calling ddi_copyin/out()? It surely relates to handling page 
> faults, so why would uiomove() not be affected?
>
> On Linux, holding a spinlock while handling a page fault is deadly as it 
> implies sleeping which is not allowed then. But then again, kmutex_t is 
> a bit smarter...
>
>   Joachim
>   

I think you're right, and it relates to page faulting.  The problem I 
can see is a recursive lock entry in a storage driver.  (It would 
probably be harmless to hold an ordinary adaptive lock in a subsystem 
that wasn't involved in handling page faults.)

That said, there is a performance implication as well.  The copy 
routines can take a while.  Normally, its a bad idea to hold a lock for 
a long time, as it usually does bad things to your concurrency.

For most normal uses of ddi_copyin/copyout, you shouldn't need a lock 
any way.  The normal practice is that the copying handles either before 
(for copyin) or after (for copyout) the main processing chunk for an 
ioctl, and you only need the locks in the main processing chunk.  (You 
can do any required data model conversions outside of the lock as well.)

I wouldn't put too much faith in what uiomove claims (or in this case 
fails to claim) -- I suspect it has the same general limitation.  It 
wouldn't be the first time that an important consideration was not 
properly documented in the man pages.

    -- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to