[PATCH 0/2] Resend of two uio patches

[PATCH 0/2] Resend of two uio patches

[Uwe Kleine-König]

Hello,

these two patches were already sent back in April but fell through the
cracks. They are not really related, but send in a series because they
fail to apply in reverse order.

Patch 1 is useful for debugging with gdb, patch 2 is a cleanup. Note
that patch 2 is only compile-tested because I don't have an uio driver
that uses a non-physical map.                                                                                                                         
Best regards
Uwe

Uwe Kleine-König (2):
  uio: provide vm access to UIO_MEM_PHYS maps
  uio: drop unused vma_count member in uio_device struct

 drivers/uio/uio.c | 38 ++++++++++++++------------------------
 1 file changed, 14 insertions(+), 24 deletions(-)

-- 
1.8.3.2

[PATCH 1/2] uio: provide vm access to UIO_MEM_PHYS maps

[Uwe Kleine-König]

This makes it possible to let gdb access mappings of the process that is
being debugged.

uio_mmap_logical was moved and uio_vm_ops renamed to group related code
and differentiate to new stuff.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 drivers/uio/uio.c | 24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 3b96f18..159cfb3 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -630,12 +630,24 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 	return 0;
 }
 
-static const struct vm_operations_struct uio_vm_ops = {
+static const struct vm_operations_struct uio_logical_vm_ops = {
 	.open = uio_vma_open,
 	.close = uio_vma_close,
 	.fault = uio_vma_fault,
 };
 
+static int uio_mmap_logical(struct vm_area_struct *vma)
+{
+	vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
+	vma->vm_ops = &uio_vm_ops;
+	uio_vma_open(vma);
+	return 0;
+}
+
+static const struct vm_operations_struct uio_physical_vm_ops = {
+	.access = generic_access_phys,
+};
+
 static int uio_mmap_physical(struct vm_area_struct *vma)
 {
 	struct uio_device *idev = vma->vm_private_data;
@@ -643,6 +655,8 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
 	if (mi < 0)
 		return -EINVAL;
 
+	vma->vm_ops = &uio_physical_vm_ops;
+
 	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
 
 	return remap_pfn_range(vma,
@@ -652,14 +666,6 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
 			       vma->vm_page_prot);
 }
 
-static int uio_mmap_logical(struct vm_area_struct *vma)
-{
-	vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
-	vma->vm_ops = &uio_vm_ops;
-	uio_vma_open(vma);
-	return 0;
-}
-
 static int uio_mmap(struct file *filep, struct vm_area_struct *vma)
 {
 	struct uio_listener *listener = filep->private_data;
-- 
1.8.3.2

Re: [PATCH 1/2] uio: provide vm access to UIO_MEM_PHYS maps

[Greg Kroah-Hartman]

On Tue, Jul 16, 2013 at 07:21:03PM +0200, Uwe Kleine-König wrote:
> This makes it possible to let gdb access mappings of the process that is
> being debugged.
> 
> uio_mmap_logical was moved and uio_vm_ops renamed to group related code
> and differentiate to new stuff.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

This patch breaks the build:

drivers/uio/uio.c: In function ‘uio_mmap_logical’:
drivers/uio/uio.c:627:17: error: ‘uio_vm_ops’ undeclared (first use in this function)

:(

Re: [PATCH 1/2] uio: provide vm access to UIO_MEM_PHYS maps

[Uwe Kleine-König]

On Fri, Jul 26, 2013 at 05:58:10PM -0700, Greg Kroah-Hartman wrote:
> On Tue, Jul 16, 2013 at 07:21:03PM +0200, Uwe Kleine-König wrote:
> > This makes it possible to let gdb access mappings of the process that is
> > being debugged.
> > 
> > uio_mmap_logical was moved and uio_vm_ops renamed to group related code
> > and differentiate to new stuff.
> > 
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> 
> This patch breaks the build:
> 
> drivers/uio/uio.c: In function ‘uio_mmap_logical’:
> drivers/uio/uio.c:627:17: error: ‘uio_vm_ops’ undeclared (first use in this function)
Hmm, in my original patch this is OK, I don't have no idea how I could
bork that for submission. While looking into that problem I noticed that
there is yet another problem. I will send a fixed patch early next week.

Best regards and thanks for testing,
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps

[Uwe Kleine-König]

This makes it possible to let gdb access mappings of the process that is
being debugged.

uio_mmap_logical was moved and uio_vm_ops renamed to group related code
and differentiate to new stuff.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Changes since v1:
    - only use generic_access_phys ifdef CONFIG_HAVE_IOREMAP_PROT
    - fix all users of renamed struct

 drivers/uio/uio.c | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 3b96f18..c4279b2 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -630,12 +630,26 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 	return 0;
 }
 
-static const struct vm_operations_struct uio_vm_ops = {
+static const struct vm_operations_struct uio_logical_vm_ops = {
 	.open = uio_vma_open,
 	.close = uio_vma_close,
 	.fault = uio_vma_fault,
 };
 
+static int uio_mmap_logical(struct vm_area_struct *vma)
+{
+	vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
+	vma->vm_ops = &uio_logical_vm_ops;
+	uio_vma_open(vma);
+	return 0;
+}
+
+static const struct vm_operations_struct uio_physical_vm_ops = {
+#ifdef CONFIG_HAVE_IOREMAP_PROT
+	.access = generic_access_phys,
+#endif
+};
+
 static int uio_mmap_physical(struct vm_area_struct *vma)
 {
 	struct uio_device *idev = vma->vm_private_data;
@@ -643,6 +657,8 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
 	if (mi < 0)
 		return -EINVAL;
 
+	vma->vm_ops = &uio_physical_vm_ops;
+
 	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
 
 	return remap_pfn_range(vma,
@@ -652,14 +668,6 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
 			       vma->vm_page_prot);
 }
 
-static int uio_mmap_logical(struct vm_area_struct *vma)
-{
-	vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
-	vma->vm_ops = &uio_vm_ops;
-	uio_vma_open(vma);
-	return 0;
-}
-
 static int uio_mmap(struct file *filep, struct vm_area_struct *vma)
 {
 	struct uio_listener *listener = filep->private_data;
-- 
1.8.3.2

[PATCH v2 2/2] uio: drop unused vma_count member in uio_device struct

[Uwe Kleine-König]

vma_count is used write-only and so fails to be useful. So remove it.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
changes since v1:
    - adapt to changes in patch 1 
 drivers/uio/uio.c | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index c4279b2..8abe78c 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -35,7 +35,6 @@ struct uio_device {
 	atomic_t		event;
 	struct fasync_struct	*async_queue;
 	wait_queue_head_t	wait;
-	int			vma_count;
 	struct uio_info		*info;
 	struct kobject		*map_dir;
 	struct kobject		*portio_dir;
@@ -593,18 +592,6 @@ static int uio_find_mem_index(struct vm_area_struct *vma)
 	return -1;
 }
 
-static void uio_vma_open(struct vm_area_struct *vma)
-{
-	struct uio_device *idev = vma->vm_private_data;
-	idev->vma_count++;
-}
-
-static void uio_vma_close(struct vm_area_struct *vma)
-{
-	struct uio_device *idev = vma->vm_private_data;
-	idev->vma_count--;
-}
-
 static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	struct uio_device *idev = vma->vm_private_data;
@@ -631,8 +618,6 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 }
 
 static const struct vm_operations_struct uio_logical_vm_ops = {
-	.open = uio_vma_open,
-	.close = uio_vma_close,
 	.fault = uio_vma_fault,
 };
 
@@ -640,7 +625,6 @@ static int uio_mmap_logical(struct vm_area_struct *vma)
 {
 	vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
 	vma->vm_ops = &uio_logical_vm_ops;
-	uio_vma_open(vma);
 	return 0;
 }
 
-- 
1.8.3.2

Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps

[Greg Kroah-Hartman]

On Sun, Jul 28, 2013 at 12:09:37AM +0200, Uwe Kleine-König wrote:
> This makes it possible to let gdb access mappings of the process that is
> being debugged.
> 
> uio_mmap_logical was moved and uio_vm_ops renamed to group related code
> and differentiate to new stuff.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Changes since v1:
>     - only use generic_access_phys ifdef CONFIG_HAVE_IOREMAP_PROT
>     - fix all users of renamed struct

I still get a build error with this patch:

  MODPOST 384 modules
ERROR: "generic_access_phys" [drivers/uio/uio.ko] undefined!

So something isn't quite right.

greg k-h

Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps

[Uwe Kleine-König]

[expanding Cc: to also include akpm and linux-mm]

Hello,

On Mon, Jul 29, 2013 at 01:09:14PM -0700, Greg Kroah-Hartman wrote:
> On Sun, Jul 28, 2013 at 12:09:37AM +0200, Uwe Kleine-König wrote:
> > This makes it possible to let gdb access mappings of the process that is
> > being debugged.
> > 
> > uio_mmap_logical was moved and uio_vm_ops renamed to group related code
> > and differentiate to new stuff.
> > 
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > Changes since v1:
> >     - only use generic_access_phys ifdef CONFIG_HAVE_IOREMAP_PROT
> >     - fix all users of renamed struct
> 
> I still get a build error with this patch:
> 
>   MODPOST 384 modules
> ERROR: "generic_access_phys" [drivers/uio/uio.ko] undefined!
> 
> So something isn't quite right.
Ah, you built as a module and generic_access_phys isn't exported. The
other users of generic_access_phys (arch/x86/pci/i386.c and
drivers/char/mem.c) can only be builtin.

So the IMHO best option is to add an EXPORT_SYMBOL(generic_access_phys)
to mm/memory.c.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps

[Greg Kroah-Hartman]

On Tue, Jul 30, 2013 at 09:52:39AM +0200, Uwe Kleine-König wrote:
> [expanding Cc: to also include akpm and linux-mm]
> 
> Hello,
> 
> On Mon, Jul 29, 2013 at 01:09:14PM -0700, Greg Kroah-Hartman wrote:
> > On Sun, Jul 28, 2013 at 12:09:37AM +0200, Uwe Kleine-König wrote:
> > > This makes it possible to let gdb access mappings of the process that is
> > > being debugged.
> > > 
> > > uio_mmap_logical was moved and uio_vm_ops renamed to group related code
> > > and differentiate to new stuff.
> > > 
> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > ---
> > > Changes since v1:
> > >     - only use generic_access_phys ifdef CONFIG_HAVE_IOREMAP_PROT
> > >     - fix all users of renamed struct
> > 
> > I still get a build error with this patch:
> > 
> >   MODPOST 384 modules
> > ERROR: "generic_access_phys" [drivers/uio/uio.ko] undefined!
> > 
> > So something isn't quite right.
> Ah, you built as a module and generic_access_phys isn't exported. The
> other users of generic_access_phys (arch/x86/pci/i386.c and
> drivers/char/mem.c) can only be builtin.
> 
> So the IMHO best option is to add an EXPORT_SYMBOL(generic_access_phys)
> to mm/memory.c.

EXPORT_SYMBOL_GPL() perhaps?

And why all of a sudden does the uio driver need this change?  It is
working just fine right now without it, right?

thanks,

greg k-h

Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps

[Uwe Kleine-König]

Hello Greg,

On Tue, Jul 30, 2013 at 06:49:50AM -0700, Greg Kroah-Hartman wrote:
> On Tue, Jul 30, 2013 at 09:52:39AM +0200, Uwe Kleine-König wrote:
> > [expanding Cc: to also include akpm and linux-mm]
> > 
> > Hello,
> > 
> > On Mon, Jul 29, 2013 at 01:09:14PM -0700, Greg Kroah-Hartman wrote:
> > > On Sun, Jul 28, 2013 at 12:09:37AM +0200, Uwe Kleine-König wrote:
> > > > This makes it possible to let gdb access mappings of the process that is
> > > > being debugged.
> > > > 
> > > > uio_mmap_logical was moved and uio_vm_ops renamed to group related code
> > > > and differentiate to new stuff.
> > > > 
> > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > > ---
> > > > Changes since v1:
> > > >     - only use generic_access_phys ifdef CONFIG_HAVE_IOREMAP_PROT
> > > >     - fix all users of renamed struct
> > > 
> > > I still get a build error with this patch:
> > > 
> > >   MODPOST 384 modules
> > > ERROR: "generic_access_phys" [drivers/uio/uio.ko] undefined!
> > > 
> > > So something isn't quite right.
> > Ah, you built as a module and generic_access_phys isn't exported. The
> > other users of generic_access_phys (arch/x86/pci/i386.c and
> > drivers/char/mem.c) can only be builtin.
> > 
> > So the IMHO best option is to add an EXPORT_SYMBOL(generic_access_phys)
> > to mm/memory.c.
> 
> EXPORT_SYMBOL_GPL() perhaps?
Yeah, that would work just fine, too. Who takes care for mm/memory.c,
Andrew? Should I send a separate patch or is it ok to do it in the patch
making use of it and let it go in via Greg?
 
> And why all of a sudden does the uio driver need this change?  It is
> working just fine right now without it, right?
Yeah it works. But if you gdb your userspace driver, gdb cannot access
the mappings without my patch.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps

[Greg Kroah-Hartman]

On Tue, Jul 30, 2013 at 04:32:37PM +0200, Uwe Kleine-König wrote:
> Hello Greg,
> 
> On Tue, Jul 30, 2013 at 06:49:50AM -0700, Greg Kroah-Hartman wrote:
> > On Tue, Jul 30, 2013 at 09:52:39AM +0200, Uwe Kleine-König wrote:
> > > [expanding Cc: to also include akpm and linux-mm]
> > > 
> > > Hello,
> > > 
> > > On Mon, Jul 29, 2013 at 01:09:14PM -0700, Greg Kroah-Hartman wrote:
> > > > On Sun, Jul 28, 2013 at 12:09:37AM +0200, Uwe Kleine-König wrote:
> > > > > This makes it possible to let gdb access mappings of the process that is
> > > > > being debugged.
> > > > > 
> > > > > uio_mmap_logical was moved and uio_vm_ops renamed to group related code
> > > > > and differentiate to new stuff.
> > > > > 
> > > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > > > ---
> > > > > Changes since v1:
> > > > >     - only use generic_access_phys ifdef CONFIG_HAVE_IOREMAP_PROT
> > > > >     - fix all users of renamed struct
> > > > 
> > > > I still get a build error with this patch:
> > > > 
> > > >   MODPOST 384 modules
> > > > ERROR: "generic_access_phys" [drivers/uio/uio.ko] undefined!
> > > > 
> > > > So something isn't quite right.
> > > Ah, you built as a module and generic_access_phys isn't exported. The
> > > other users of generic_access_phys (arch/x86/pci/i386.c and
> > > drivers/char/mem.c) can only be builtin.
> > > 
> > > So the IMHO best option is to add an EXPORT_SYMBOL(generic_access_phys)
> > > to mm/memory.c.
> > 
> > EXPORT_SYMBOL_GPL() perhaps?
> Yeah, that would work just fine, too. Who takes care for mm/memory.c,
> Andrew? Should I send a separate patch or is it ok to do it in the patch
> making use of it and let it go in via Greg?

I can take it, in a patch before this one, if I get the acks from Andrew
and anyone else who "owns" that file (use get_maintainer.pl to determine
the proper people please.)

> > And why all of a sudden does the uio driver need this change?  It is
> > working just fine right now without it, right?
> Yeah it works. But if you gdb your userspace driver, gdb cannot access
> the mappings without my patch.

Ah, but who needs to use a debugger... :)

thanks,

greg k-h

[PATCH 2/2] uio: drop unused vma_count member in uio_device struct

[Uwe Kleine-König]

vma_count is used write-only and so fails to be useful. So remove it.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 drivers/uio/uio.c | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 159cfb3..af24bda 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -35,7 +35,6 @@ struct uio_device {
 	atomic_t		event;
 	struct fasync_struct	*async_queue;
 	wait_queue_head_t	wait;
-	int			vma_count;
 	struct uio_info		*info;
 	struct kobject		*map_dir;
 	struct kobject		*portio_dir;
@@ -593,18 +592,6 @@ static int uio_find_mem_index(struct vm_area_struct *vma)
 	return -1;
 }
 
-static void uio_vma_open(struct vm_area_struct *vma)
-{
-	struct uio_device *idev = vma->vm_private_data;
-	idev->vma_count++;
-}
-
-static void uio_vma_close(struct vm_area_struct *vma)
-{
-	struct uio_device *idev = vma->vm_private_data;
-	idev->vma_count--;
-}
-
 static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	struct uio_device *idev = vma->vm_private_data;
@@ -631,8 +618,6 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 }
 
 static const struct vm_operations_struct uio_logical_vm_ops = {
-	.open = uio_vma_open,
-	.close = uio_vma_close,
 	.fault = uio_vma_fault,
 };
 
@@ -640,7 +625,6 @@ static int uio_mmap_logical(struct vm_area_struct *vma)
 {
 	vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
 	vma->vm_ops = &uio_vm_ops;
-	uio_vma_open(vma);
 	return 0;
 }
 
-- 
1.8.3.2

Re: [PATCH 0/2] Resend of two uio patches

[Greg Kroah-Hartman]

On Tue, Jul 16, 2013 at 07:21:02PM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> these two patches were already sent back in April but fell through the
> cracks. They are not really related, but send in a series because they
> fail to apply in reverse order.
> 
> Patch 1 is useful for debugging with gdb, patch 2 is a cleanup. Note
> that patch 2 is only compile-tested because I don't have an uio driver
> that uses a non-physical map.                                                                                                                         
> Best regards
> Uwe

Thanks, I'll go through these later this week.

greg k-h

[PATCH 0/2] some uio patches

[Uwe Kleine-König]

Hello,

these two patches are not really related, I only sent them in a series because
they touch the same file and fail to apply in reversed order.

Patch 1 is useful for debugging with gdb, patch 2 is a cleanup. Note that patch
2 is only compile-tested because I don't have an uio driver that uses a
non-physical map.

Best regards
Uwe

Uwe Kleine-König (2):
  uio: provide vm access to UIO_MEM_PHYS maps
  uio: drop unused vma_count member in uio_device struct

 drivers/uio/uio.c | 38 ++++++++++++++------------------------
 1 file changed, 14 insertions(+), 24 deletions(-)

-- 
1.8.2.rc2

[PATCH 1/2] uio: provide vm access to UIO_MEM_PHYS maps

[Uwe Kleine-König]

This makes it possible to let gdb access mappings of the process that is
being debugged.

uio_mmap_logical was moved and uio_vm_ops renamed to group related code
and differentiate to new stuff.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 drivers/uio/uio.c | 24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index c8b9262..f9c905a 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -629,12 +629,24 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 	return 0;
 }
 
-static const struct vm_operations_struct uio_vm_ops = {
+static const struct vm_operations_struct uio_logical_vm_ops = {
 	.open = uio_vma_open,
 	.close = uio_vma_close,
 	.fault = uio_vma_fault,
 };
 
+static int uio_mmap_logical(struct vm_area_struct *vma)
+{
+	vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
+	vma->vm_ops = &uio_vm_ops;
+	uio_vma_open(vma);
+	return 0;
+}
+
+static const struct vm_operations_struct uio_physical_vm_ops = {
+	.access = generic_access_phys,
+};
+
 static int uio_mmap_physical(struct vm_area_struct *vma)
 {
 	struct uio_device *idev = vma->vm_private_data;
@@ -642,6 +654,8 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
 	if (mi < 0)
 		return -EINVAL;
 
+	vma->vm_ops = &uio_physical_vm_ops;
+
 	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
 
 	return remap_pfn_range(vma,
@@ -651,14 +665,6 @@ static int uio_mmap_physical(struct vm_area_struct *vma)
 			       vma->vm_page_prot);
 }
 
-static int uio_mmap_logical(struct vm_area_struct *vma)
-{
-	vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
-	vma->vm_ops = &uio_vm_ops;
-	uio_vma_open(vma);
-	return 0;
-}
-
 static int uio_mmap(struct file *filep, struct vm_area_struct *vma)
 {
 	struct uio_listener *listener = filep->private_data;
-- 
1.8.2.rc2