[Xenomai-core] [patch] fault mmaped area upon rtdm_mmap_to_user.

[Xenomai-core] [patch] fault mmaped area upon rtdm_mmap_to_user.

[Gilles Chanteperdrix]

Hi Jan,

I have just commited a modification of the nucleus heap which allows
faulting newly mapped pages. However, I noticed that we should modify
rtdm_mmap_to_user as in the attached patch.

At this chance, I also noticed that there is no way to ask for uncached
memory to rtdm_mmap_to_user, how do you think we should change
rtdm_mmap_to_user to allow this?

Regards.

Index: ksrc/skins/rtdm/drvlib.c
===================================================================
--- ksrc/skins/rtdm/drvlib.c	(revision 4390)
+++ ksrc/skins/rtdm/drvlib.c	(working copy)
@@ -1781,6 +1781,7 @@ static int rtdm_mmap_buffer(struct file
 {
 	struct rtdm_mmap_data *mmap_data = filp->private_data;
 	unsigned long vaddr, paddr, maddr, size;
+	int ret;

 	vma->vm_ops = mmap_data->vm_ops;
 	vma->vm_private_data = mmap_data->vm_private_data;
@@ -1810,15 +1811,25 @@ static int rtdm_mmap_buffer(struct file
 			vaddr += PAGE_SIZE;
 			mapped_size += PAGE_SIZE;
 		}
-		return 0;
+#ifdef xnarch_fault_range
+		xnarch_fault_range(vma);
+#endif /* xnarch_fault_range */
+		ret = 0;
 	} else
 #endif /* CONFIG_MMU */
 	if (mmap_data->src_paddr)
-	  	return xnarch_remap_io_page_range(filp, vma, maddr, paddr,
-						  size, PAGE_SHARED);
-	else
-		return xnarch_remap_kmem_page_range(vma, maddr, paddr,
-						    size, PAGE_SHARED);
+	  	ret = xnarch_remap_io_page_range(filp, vma, maddr, paddr,
+						 size, PAGE_SHARED);
+	else {
+		ret = xnarch_remap_kmem_page_range(vma, maddr, paddr,
+						   size, PAGE_SHARED);
+#ifdef xnarch_fault_range
+		if (!ret)
+			xnarch_fault_range(vma);
+#endif /* xnarch_fault_range */
+	}
+
+	return ret;
 }

 static struct file_operations rtdm_mmap_fops = {


-- 
					    Gilles.

Re: [Xenomai-core] [patch] fault mmaped area upon rtdm_mmap_to_user.

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2176 bytes --]

Gilles Chanteperdrix wrote:
> Hi Jan,
> 
> I have just commited a modification of the nucleus heap which allows
> faulting newly mapped pages. However, I noticed that we should modify
> rtdm_mmap_to_user as in the attached patch.

No general concerns, please just provide an empty xnarch_fault_range as
default to avoid the #ifdefs. Is this an ARM-only issue?

> 
> At this chance, I also noticed that there is no way to ask for uncached
> memory to rtdm_mmap_to_user, how do you think we should change
> rtdm_mmap_to_user to allow this?

Look like we would have to introduce a 'flags' argument to
rtdm_mmap_to_user. That's 2.5 material, where we'll change a few RTDM
APIs anyway.

Jan

> 
> Regards.
> 
> Index: ksrc/skins/rtdm/drvlib.c
> ===================================================================
> --- ksrc/skins/rtdm/drvlib.c	(revision 4390)
> +++ ksrc/skins/rtdm/drvlib.c	(working copy)
> @@ -1781,6 +1781,7 @@ static int rtdm_mmap_buffer(struct file
>  {
>  	struct rtdm_mmap_data *mmap_data = filp->private_data;
>  	unsigned long vaddr, paddr, maddr, size;
> +	int ret;
> 
>  	vma->vm_ops = mmap_data->vm_ops;
>  	vma->vm_private_data = mmap_data->vm_private_data;
> @@ -1810,15 +1811,25 @@ static int rtdm_mmap_buffer(struct file
>  			vaddr += PAGE_SIZE;
>  			mapped_size += PAGE_SIZE;
>  		}
> -		return 0;
> +#ifdef xnarch_fault_range
> +		xnarch_fault_range(vma);
> +#endif /* xnarch_fault_range */
> +		ret = 0;
>  	} else
>  #endif /* CONFIG_MMU */
>  	if (mmap_data->src_paddr)
> -	  	return xnarch_remap_io_page_range(filp, vma, maddr, paddr,
> -						  size, PAGE_SHARED);
> -	else
> -		return xnarch_remap_kmem_page_range(vma, maddr, paddr,
> -						    size, PAGE_SHARED);
> +	  	ret = xnarch_remap_io_page_range(filp, vma, maddr, paddr,
> +						 size, PAGE_SHARED);
> +	else {
> +		ret = xnarch_remap_kmem_page_range(vma, maddr, paddr,
> +						   size, PAGE_SHARED);
> +#ifdef xnarch_fault_range
> +		if (!ret)
> +			xnarch_fault_range(vma);
> +#endif /* xnarch_fault_range */
> +	}
> +
> +	return ret;
>  }
> 
>  static struct file_operations rtdm_mmap_fops = {
> 
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]