Add gfp_mask to get_vm_area()

Dave, please consider this patch. It renames get_vm_area() to __get_vm_area() and adds a gfp_mask parameter which is passed on to kmalloc(). get_vm_area(size,flags) is then defined as as __get_vm_area(size,flags,GFP_KERNEL) to avoid messing with existing callers.

We need this in order to sanely make pci_alloc_consistent() (and other consistent allocation functions) obey the DMA-mapping.txt rules on PPC embedded machines (specifically the requirement that it be callable from interrupt context).

Quoted 7 lines · David Gibson

Dave, please consider this patch. It renames get_vm_area() to __get_vm_area() and adds a gfp_mask parameter which is passed on to kmalloc(). get_vm_area(size,flags) is then defined as as __get_vm_area(size,flags,GFP_KERNEL) to avoid messing with existing callers.

Quoted 5 lines

We need this in order to sanely make pci_alloc_consistent() (and other consistent allocation functions) obey the DMA-mapping.txt rules on PPC embedded machines (specifically the requirement that it be callable from interrupt context).

I can look after that for you. But I'd prefer that you just add the extra gfp_flags argument to get_vm_area() and update the 16 callers.

You cannot call get_vm_area() from interrupt context at present; it does write_lock(&vmlist_lock) unsafely.

It would be a bit sad to make vmlist_lock interrupt-safe for this. Is there no alternative?

(And what the hell is arch/alpha/mm/init.c:callback_init() doing rewriting vmlist? Somebody shoot that code)

I don't see an easy one: PPC 4xx has non-coherent cache, so we have to mark consistent memory non-cacheable. We want to make the normal lowmem mapping use large page TLB entries, so we can't frob the attribute bits on the pages in place. That means we need to create a new, non-cacheable mapping for the physical RAM we allocate, which in turn means allocating a chunk of kernel virtual memory.

Quoted 6 lines · David Gibson

I don't see an easy one: PPC 4xx has non-coherent cache, so we have to mark consistent memory non-cacheable. We want to make the normal lowmem mapping use large page TLB entries, so we can't frob the attribute bits on the pages in place. That means we need to create a new, non-cacheable mapping for the physical RAM we allocate, which in turn means allocating a chunk of kernel virtual memory.

Same problem on ARM. I just haven't got the motivation to rewrite the bits of the kernel that need to be rewritten to make it work.

Have you checked that your pte/pmd allocation functions can be called from IRQ context as well?

You basically need:

- irq-safe get_vm_area
- irq-safe pmd_alloc_kernel
- irq-safe pte_alloc_kernel

Last time I looked, all the above were not irq-safe.

Quoted 15 lines · Andrew Morton

Quoted 7 lines · David Gibson

Dave, please consider this patch. It renames get_vm_area() to __get_vm_area() and adds a gfp_mask parameter which is passed on to kmalloc(). get_vm_area(size,flags) is then defined as as __get_vm_area(size,flags,GFP_KERNEL) to avoid messing with existing callers.

Quoted 5 lines

We need this in order to sanely make pci_alloc_consistent() (and other consistent allocation functions) obey the DMA-mapping.txt rules on PPC embedded machines (specifically the requirement that it be callable from interrupt context).

Quoted 5 lines

I can look after that for you. But I'd prefer that you just add the extra gfp_flags argument to get_vm_area() and update the 16 callers.

You cannot call get_vm_area() from interrupt context at present; it does write_lock(&vmlist_lock) unsafely.

Oh crap, I'm an idiot. I've even seen prototype patches for this one that changed the write_lock() to write_lock_irq(). Duh.

Quoted 2 lines

It would be a bit sad to make vmlist_lock interrupt-safe for this. Is there no alternative?

I don't see an easy one: PPC 4xx has non-coherent cache, so we have to mark consistent memory non-cacheable. We want to make the normal lowmem mapping use large page TLB entries, so we can't frob the attribute bits on the pages in place. That means we need to create a new, non-cacheable mapping for the physical RAM we allocate, which in turn means allocating a chunk of kernel virtual memory.

Quoted 29 lines · David Gibson

Quoted 15 lines · Andrew Morton

Quoted 7 lines · David Gibson

Dave, please consider this patch. It renames get_vm_area() to __get_vm_area() and adds a gfp_mask parameter which is passed on to kmalloc(). get_vm_area(size,flags) is then defined as as __get_vm_area(size,flags,GFP_KERNEL) to avoid messing with existing callers.

Quoted 5 lines

We need this in order to sanely make pci_alloc_consistent() (and other consistent allocation functions) obey the DMA-mapping.txt rules on PPC embedded machines (specifically the requirement that it be callable from interrupt context).

Quoted 5 lines

I can look after that for you. But I'd prefer that you just add the extra gfp_flags argument to get_vm_area() and update the 16 callers.

You cannot call get_vm_area() from interrupt context at present; it does write_lock(&vmlist_lock) unsafely.

Oh crap, I'm an idiot. I've even seen prototype patches for this one that changed the write_lock() to write_lock_irq(). Duh.

Quoted 2 lines

It would be a bit sad to make vmlist_lock interrupt-safe for this. Is there no alternative?

Quoted 6 lines

I don't see an easy one: PPC 4xx has non-coherent cache, so we have to mark consistent memory non-cacheable. We want to make the normal lowmem mapping use large page TLB entries, so we can't frob the attribute bits on the pages in place. That means we need to create a new, non-cacheable mapping for the physical RAM we allocate, which in turn means allocating a chunk of kernel virtual memory.

Well, here is an updated patch which should make the vmlist_lock interrupt-safe. It makes __get_vm_area() and remove_vm_area() callable from interrupt context. If you can think of some way of avoiding doing that, I'd love to hear it - I agree this would be rather sad.

Blah. It gets worse. Making map_page() or remap_page_range() interrupt-safe would require making mm->page_table_lock irq-safe too :-(

Maybe non-coherent architectures should should pre-allocate a chunk of virtual memory for consistent allocations, and pre-allocate all its page tables.

Quoted 7 lines · David Gibson

Blah. It gets worse. Making map_page() or remap_page_range() interrupt-safe would require making mm->page_table_lock irq-safe too :-(

Maybe non-coherent architectures should should pre-allocate a chunk of virtual memory for consistent allocations, and pre-allocate all its page tables.

There are a growing number of applications out there for ARM stuff where this would be impractical. Those wanting about 3GB of kernel space vs 1GB user space.

Doubling the virtual requirement for the SDRAM will make Linux unusable in these situations, and then you'll have nice people from Intel and Montavista banging on your door asking you why you killed their product line.

The current situation on ARM works for 95% of cases. If the choice is between "95% working" and "cutting off the hand that feeds you" I'd prefer the former.

On a more constructive note, I believe there is a way around the mm->page_table_lock problem. I believe we should completely split the handling of the user space page tables from the kernel space page tables.

User space can carry on using mm->page_table_lock and be happy; it should never ever touch the kernel page tables.

We then only have to worry about making things that touch the kernel page tables irq-safe. How many of those are there? Two. ioremap and vmalloc. Neither of these two functions has any business touching anything other than pid0's tables, and certainly has no business touching user space page tables. The problem is now far easier to deal with.

remap_page_range() shouldn't be a problem - its supposed to map pages into user space, and if you're calling that from IRQ context, you're doing something really wrong.

If I can get out of my current circle of never-ending problems and paid- for work on other areas of ARM stuff, I might be able to look at this. I've currently got an estimated backlog of one whole week on anything I do atm.