From mboxrd@z Thu Jan  1 00:00:00 1970
From: Don Dutile <ddutile@redhat.com>
Subject: Re: swiotlb
Date: Thu, 13 Apr 2006 21:51:28 -0400
Message-ID: <443F0020.6060300@redhat.com>
References: <443E7C63.E57C.0030.0@novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <443E7C63.E57C.0030.0@novell.com>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Ky Srinivasan <ksrinivasan@novell.com>
Cc: xen-devel@lists.xensource.com, Don Dutile <ddutile@redhat.com>
List-Id: xen-devel@lists.xenproject.org

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