Re: [Patch] Do not copy from remote while in_atomic()

Aboslutely correct.

Kris, can you please apply to the release tree? Tab?

moshe


On Mar 23, 2006, at 4:37 AM, Ansgar Esztermann wrote:

> Here is a patch for CONFIG_HIGHMEM enabled kernels.
>
> Some kernel functions use kmap_atomic() rather than kmap() to map a
> page before copying data from user space. While this is faster, atomic
> maps pose a problem with OpenMosix: deputy_copy_from_user() has to
> get the data over the network; the network code in turn might
> reschedule, which will lead to a "scheduling while atomic" error
> message. Worse, the copied data may be corrupted.
> One of the functions affected is the write() system call.
>
> The following patch makes deputy_copy_*_user() fail gracefully in this
> case. The calling function then has the opportunity to retry the
> operation using non-atomic maps instead.
>
>
> A.
>
>
>
> diff -ruNp linux-2.6-om/hpc/copyuser.c linux-2.6-om-work/hpc/ 
> copyuser.c
> --- linux-2.6-om/hpc/copyuser.c	2006-02-07 16:51:58.000000000 +0100
> +++ linux-2.6-om-work/hpc/copyuser.c	2006-03-22 15:43:52.000000000  
> +0100
> @@ -27,6 +27,9 @@ unsigned long deputy_copy_from_user(void
>  {
>  	struct omp_usercopy_req u;
>  	int error;
> +
> +	if (in_atomic())
> +		return n;
>  	
>  	u.addr = (unsigned long) from;
>  	u.len = n;
> @@ -82,6 +85,9 @@ unsigned long deputy_copy_to_user(void _
>  {
>  	struct omp_usercopy_req u;
>  	int error;
> +
> +	if (in_atomic())
> +		return n;
>  	
>  	OMDEBUG_CPYUSER(1, "copy [0x%p]->user[0x%p][%ld]\n", from, to, n);
>  	u.addr = (unsigned long) to;
>
>
> -- 
> Ansgar Esztermann
> Researcher & Sysadmin
> http://www2.thphy.uni-duesseldorf.de/~ansgar



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642