Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps
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 > > > > > --- > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps
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 > > > > --- > > > > 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/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps
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 > > > --- > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps
[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 > > --- > > 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/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps
[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-koe...@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/ | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps
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-koe...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps
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-koe...@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/ | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps
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-koe...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps
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 > --- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps
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-koe...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps
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
---
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 = _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 = _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 = _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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] uio: provide vm access to UIO_MEM_PHYS maps
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-koe...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
