DMA on stack?

[Marcelo Tosatti]

On Tue, Nov 13, 2007 at 03:24:46PM -0500, Dan Williams wrote:
> On Tue, 2007-11-13 at 11:14 -0800, Pete Zaitcev wrote:
> > On Tue, 13 Nov 2007 10:09:58 -0500, Dan Williams <dcbw at redhat.com> wrote:
> > > On Tue, 2007-11-13 at 16:10 +0100, Oliver Neukum wrote:
> > 
> > > > has anybody verified that this code: (if_usb.c::if_usb_suspend)
> > 
> > > > 		libertas_prepare_and_send_command(priv,
> > > > 				CMD_MESH_ACCESS,
> > > > 				CMD_ACT_MESH_SET_AUTOSTART_ENABLED,
> > > > 				CMD_OPTION_WAITFORRSP, 0, (void *)&mesh_access);
> > > > 
> > > > does not do DMA on the stack?
> > > 
> > > I don't think so, no.
> > 
> > XO uses an x86 compatible non-SMP AMD CPU, so there's no problem with
> > DMA to stack. If they had an SMP x86_64 or ARM, they'd find this
> > in 5 minutes. BTW, where did you find that? I'd like to have a look
> 
> It should just be in wireless-2.6/everything as well as 2.6.23.  Note
> that all patches that are completely OLPC specific are in the OLPC
> kernel git tree, and what's in wireless-2.6 is fully functional and
> suitable for upstream without OLPC private ioctls and such.  olpc-2.6
> notably has a lot of the custom suspend/resume hacks that were necessary
> for fast suspend/resume on XO hardware, which wireless-2.6 doesn't have
> for obvious reasons.
> 
> However, if there's a possibility that the above snipped could have
> problems on CPUs other than the XOs, we should figure out a way to fix
> it.  It's not too high a priority since there aren't any 8388 USB
> dongles out there other than the reference boards that a few people have
> (and the mesh firmware only runs on 8388 parts), but it should still get
> fixed for correctness' sake.

Not an issue since that data is copied to a SLAB allocated region before
submission to HW.