Messages in this thread | | | Date | Tue, 29 Dec 1998 15:48:01 -0600 | From | David Grothe <> | Subject | Re: get_vm_area and GFP_KERNEL |
| |
Benjamin C.R. LaHaise wrote:
> On Thu, 22 Oct 1998, David Grothe wrote: > > ... > > The problem: If these routines are called from a bottom half task queue > > routine then kmalloc thinks that it is being called from interrupt level > > without GFP_ATOMIC and prints a message to that effect. > > But who is calling ioremap or vremap from a bottom half? That isn't > permitted! Device drivers are supposed to setup their mappings ahead of > time, right?
Not in my case. I have drivers that execute queued requests from a bottom half routine. The driver accepts configuration information from a user-space utility that runs long after boot time. The configuration information specifies such hardware parameters as IRQ and shared memory address.
I don't understand what the problem is here. When get_vm_area is called with GFP_KERNEL and it finds itself "at interrupt level", it simply changes the priority parameter to GFP_ATOMIC and proceeds with the request. The allocation routines seem to have code in them to protect critical sections from being interrupted.
So why have the restriction on when device memory can be mapped? Or why not create a variant of ioremap/vremap with a "priority" parameter so that I can have some control over this?
Thanks, Dave
> > > > Would any harm be done by changing this? > > Yes, reliability of vmalloc/ioremap would be degraded, whereas many of the > callers expect the system to make a reasonable attempt to perform the > operation (we all know about the sound & floppy driver transient failures > due to DMA). If such a hack must be added, it should use something like > the gfp_any macro.
If so, then why does get_vm_area simply change the value of the priority parameter and proceed with the request?
-- Dave
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |