> 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/