Given that the function __sync_single() can be called in an interrupt context, why do we call a potentially blocking function (__copy_to_user) from within this function? Regards, K. Y _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ky, You are correct. I received this as a bugzilla on FC-5. Testing a solution now (replacing copy_to_user w/copy_to_user_inatomic). The other problem with the call to copy_to_user is that a kmap_atomic() is done just before it as well, and the thread can''t be blocked before the kunmap_atomic() is invoked (after the copy_to_user()). Unfortunately, tomorrow is company holiday, so I won''t complete the testing until Monday; need to get more memory to force swiotlb''s sync_single() to do the copy (due to bounce IO). - Don Ky Srinivasan wrote:> Given that the function __sync_single() can be called in an interrupt > context, why do we call a potentially blocking function > (__copy_to_user) from within this function? > > Regards, > > K. Y > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13 Apr 2006, at 21:29, Ky Srinivasan wrote:> Given that the function __sync_single() can be called in an interrupt > context, why do we call a potentially blocking function > (__copy_to_user) from within this function?Good point. Would __copy_to_user_inatomic() be safe? It avoids might_sleep(). We know that the page fault itself (if any) will not block on I/O -- we only use __copy_to_user() to safely catch the fault and return. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks Don. I am seeing this problem on SLES10 as well. I will wait for your fix. K. Y>>> Don Dutile <ddutile@redhat.com> 04/13/06 9:51 pm >>>Ky, You are correct. I received this as a bugzilla on FC- 5. Testing a solution now (replacing copy_to_user w/copy_to_user_inatomic). The other problem with the call to copy_to_user is that a kmap_atomic() is done just before it as well, and the thread can''t be blocked before the kunmap_atomic() is invoked (after the copy_to_user()). Unfortunately, tomorrow is company holiday, so I won''t complete the testing until Monday; need to get more memory to force swiotlb''s sync_single() to do the copy (due to bounce IO). - Don Ky Srinivasan wrote:> Given that the function __sync_single() can be called in aninterrupt> context, why do we call a potentially blocking function > (__copy_to_user) from within this function? > > Regards, > > K. Y > > > _______________________________________________ > Xen- devel mailing list > Xen- devel@lists.xensource.com > http://lists.xensource.com/xen- devel_______________________________________________ Xen- devel mailing list Xen- devel@lists.xensource.com http://lists.xensource.com/xen- devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
That should do the trick. K. Y>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 04/14/06 2:50 am >>>On 13 Apr 2006, at 21:29, Ky Srinivasan wrote:> Given that the function __sync_single() can be called in aninterrupt> context, why do we call a potentially blocking function > (__copy_to_user) from within this function?Good point. Would __copy_to_user_inatomic() be safe? It avoids might_sleep(). We know that the page fault itself (if any) will not block on I/O -- we only use __copy_to_user() to safely catch the fault and return. -- Keir _______________________________________________ Xen- devel mailing list Xen- devel@lists.xensource.com http://lists.xensource.com/xen- devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel