consistent_alloc from an interrupt context

consistent_alloc from an interrupt context

[Eugene Surovegin]

Hi!

Current PPC implementation of consistent_alloc cannot be called from an
interrupt context.
This function is used by pci_alloc_consistent when
CONFIG_NOT_COHERENT_CACHE is defined.

Unfortunately it contradicts Documentation/DMA-mapping.txt which clearly
states that pci_alloc_consistent can be called from an interrupt context,
and some drivers breaks under PPC because of it.

The only part of consistent_alloc that may sleep is a call to get_vm_area.

I did quick (and dirty) fix for this problem.
I reserved a virtual address space  of a reasonable size (16M), and later
just use some part of it for real page allocations when called from
interrupt context. No deallocation support :( though

Correct implementation will require something like stuff from vmaloc.c and
it seems like a lot of code duplication to me.

So, my question to "big guys" here :), is there a better way to implement this?

Thanks,

  Eugene Surovegin <mailto:ebs@innocent.com>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: consistent_alloc from an interrupt context

[Dan Malek]

Eugene Surovegin wrote:

> Current PPC implementation of consistent_alloc cannot be called from an
> interrupt context.

Hmmmm.....Why did I think this was corrected in the past?  I see all of
the consistent_alloc users are doing the same thing.  I know we discussed
this, and the solution was actually quite trivial.  All we have to do is
pass a GFP_ATOMIC into the kmalloc() (called by get_vm_area()).  IIRC,
we added a 'gfp' parameter to get_vm_area() (and changed all callers, which
was just a few), and then passed the 'gfp' into the kmalloc().  I know
many of us tried it and everything worked sweetly :-)

I thought the change was readily accepted by the generic code powers, I guess
no one actually checked it in :-)  You could make the change locally and have
a good day :-)  All you have to do is add the parameter to get_vm_area(),
find all of the places it is currently called and add 'GFP_KERNEL' as the
parameter.  In consistent_alloc(), just pass the 'gfp' variable.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: consistent_alloc from an interrupt context

[Eugene Surovegin]

Dan,

At 09:05 PM 6/12/2002, you wrote:
Hmmmm.....Why did I think this was corrected in the past?  I see all of
>the consistent_alloc users are doing the same thing.  I know we discussed
>this, and the solution was actually quite trivial.  All we have to do is
>pass a GFP_ATOMIC into the kmalloc() (called by get_vm_area()).  IIRC,
>we added a 'gfp' parameter to get_vm_area() (and changed all callers, which
>was just a few), and then passed the 'gfp' into the kmalloc().  I know
>many of us tried it and everything worked sweetly :-)
>
>I thought the change was readily accepted by the generic code powers, I guess
>no one actually checked it in :-)  You could make the change locally and have
>a good day :-)  All you have to do is add the parameter to get_vm_area(),
>find all of the places it is currently called and add 'GFP_KERNEL' as the
>parameter.  In consistent_alloc(), just pass the 'gfp' variable.

I thought of it, but is it OK to modify arch-independent code with such a hack?

Maybe this is the reason it never was accepted.

Though, it's obviously much simpler than solution I used :)


  Eugene Surovegin <mailto:ebs@innocent.com>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: consistent_alloc from an interrupt context

[Dan Malek]

Eugene Surovegin wrote:

> I thought of it, but is it OK to modify arch-independent code with such
> a hack?

It's OK in your own code, I probably still have some around that looks
like that :-)

> Maybe this is the reason it never was accepted.

I'll have to search for the messages where this was discussed and see what
happened.  I know it wasn't discussed on the PowerPC lists, it was on some
other processor I was using.  I was just able to make the same changes and
test it on 8xx as well.

> Though, it's obviously much simpler than solution I used :)

Hey, whatever works......it's a hacker's world :-)


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/