Re: [RFC][PATCH 2/2] ARM: ioremap: Add IO mapping space reused support.
On Tue, May 13, 2014 at 09:45:08AM +0800, Richard Lee wrote: > > On Mon, May 12, 2014 at 3:51 PM, Arnd Bergmann wrote: > > On Monday 12 May 2014 10:19:55 Richard Lee wrote: > >> For the IO mapping, for the same physical address space maybe > >> mapped more than one time, for example, in some SoCs: > >> 0x2000 ~ 0x20001000: are global control IO physical map, > >> and this range space will be used by many drivers. > >> And then if each driver will do the same ioremap operation, we > >> will waste to much malloc virtual spaces. > >> > >> This patch add IO mapping space reused support. > >> > >> Signed-off-by: Richard Lee > > > > What happens if the first driver then unmaps the area? > > If the first driver will unmap the area, it shouldn't do any thing > except decreasing the 'used' counter. It's still racy. What if the first driver manage to decrement the used counter, unmaps the regions but doesn't yet free the vm_struct while another driver finds the vm_struct, increments the used count and assumes it can use it? BTW, vm_area_is_aready_to_free() name implies a query but it has side-effects like decrementing the counter. -- Catalin -- 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: [RFC][PATCH 2/2] ARM: ioremap: Add IO mapping space reused support.
On Tue, May 13, 2014 at 4:43 PM, Arnd Bergmann wrote: > On Tuesday 13 May 2014 09:45:08 Richard Lee wrote: >> > On Mon, May 12, 2014 at 3:51 PM, Arnd Bergmann wrote: >> > On Monday 12 May 2014 10:19:55 Richard Lee wrote: >> >> For the IO mapping, for the same physical address space maybe >> >> mapped more than one time, for example, in some SoCs: >> >> 0x2000 ~ 0x20001000: are global control IO physical map, >> >> and this range space will be used by many drivers. >> >> And then if each driver will do the same ioremap operation, we >> >> will waste to much malloc virtual spaces. >> >> >> >> This patch add IO mapping space reused support. >> >> >> >> Signed-off-by: Richard Lee >> > >> > What happens if the first driver then unmaps the area? >> > >> >> If the first driver will unmap the area, it shouldn't do any thing >> except decreasing the 'used' counter. > > Ah, for some reason I didn't see your first patch that introduces > that counter. > It's "[PATCH 1/2] mm/vmalloc: Add IO mapping space reused". Thanks, BRs Richard > Arnd -- 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: [RFC][PATCH 2/2] ARM: ioremap: Add IO mapping space reused support.
On Tuesday 13 May 2014 09:45:08 Richard Lee wrote: > > On Mon, May 12, 2014 at 3:51 PM, Arnd Bergmann wrote: > > On Monday 12 May 2014 10:19:55 Richard Lee wrote: > >> For the IO mapping, for the same physical address space maybe > >> mapped more than one time, for example, in some SoCs: > >> 0x2000 ~ 0x20001000: are global control IO physical map, > >> and this range space will be used by many drivers. > >> And then if each driver will do the same ioremap operation, we > >> will waste to much malloc virtual spaces. > >> > >> This patch add IO mapping space reused support. > >> > >> Signed-off-by: Richard Lee > > > > What happens if the first driver then unmaps the area? > > > > If the first driver will unmap the area, it shouldn't do any thing > except decreasing the 'used' counter. Ah, for some reason I didn't see your first patch that introduces that counter. Arnd -- 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: [RFC][PATCH 2/2] ARM: ioremap: Add IO mapping space reused support.
> On Mon, May 12, 2014 at 3:51 PM, Arnd Bergmann wrote: > On Monday 12 May 2014 10:19:55 Richard Lee wrote: >> For the IO mapping, for the same physical address space maybe >> mapped more than one time, for example, in some SoCs: >> 0x2000 ~ 0x20001000: are global control IO physical map, >> and this range space will be used by many drivers. >> And then if each driver will do the same ioremap operation, we >> will waste to much malloc virtual spaces. >> >> This patch add IO mapping space reused support. >> >> Signed-off-by: Richard Lee > > What happens if the first driver then unmaps the area? > If the first driver will unmap the area, it shouldn't do any thing except decreasing the 'used' counter. Thanks, BRs Richard Lee > Arnd -- 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: [RFC][PATCH 2/2] ARM: ioremap: Add IO mapping space reused support.
On Monday 12 May 2014 10:19:55 Richard Lee wrote: > For the IO mapping, for the same physical address space maybe > mapped more than one time, for example, in some SoCs: > 0x2000 ~ 0x20001000: are global control IO physical map, > and this range space will be used by many drivers. > And then if each driver will do the same ioremap operation, we > will waste to much malloc virtual spaces. > > This patch add IO mapping space reused support. > > Signed-off-by: Richard Lee What happens if the first driver then unmaps the area? Arnd -- 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/
[RFC][PATCH 2/2] ARM: ioremap: Add IO mapping space reused support.
For the IO mapping, for the same physical address space maybe
mapped more than one time, for example, in some SoCs:
0x2000 ~ 0x20001000: are global control IO physical map,
and this range space will be used by many drivers.
And then if each driver will do the same ioremap operation, we
will waste to much malloc virtual spaces.
This patch add IO mapping space reused support.
Signed-off-by: Richard Lee
---
arch/arm/mm/ioremap.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index f9c32ba..26a3744 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -260,7 +260,7 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
{
const struct mem_type *type;
int err;
- unsigned long addr;
+ unsigned long addr, off;
struct vm_struct *area;
phys_addr_t paddr = __pfn_to_phys(pfn);
@@ -301,6 +301,12 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
if (WARN_ON(pfn_valid(pfn)))
return NULL;
+ area = find_vm_area_paddr(paddr, size, &off, VM_IOREMAP);
+ if (area) {
+ addr = (unsigned long)area->addr;
+ return (void __iomem *)(offset + off + addr);
+ }
+
area = get_vm_area_caller(size, VM_IOREMAP, caller);
if (!area)
return NULL;
@@ -410,6 +416,9 @@ void __iounmap(volatile void __iomem *io_addr)
if (svm)
return;
+ if (!vm_area_is_aready_to_free((unsigned long)addr))
+ return;
+
#if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE)
{
struct vm_struct *vm;
--
1.8.4
--
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/
