public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Petko Manolov <petkan@nucleusys.com>
To: Steve Calfee <stevecalfee@gmail.com>
Cc: "Greg KH" <greg@kroah.com>, "Ben Hutchings" <ben@decadent.org.uk>,
	netdev@vger.kernel.org, "USB list" <linux-usb@vger.kernel.org>,
	"Lisandro Damián Nicanor Pérez Meyer" <lisandro@debian.org>
Subject: Re: [PATCH net 1/4] pegasus: Use heap buffers for all register access
Date: Wed, 8 Feb 2017 09:57:36 +0200	[thread overview]
Message-ID: <20170208075736.clhgooyed5rvr3ng@p310> (raw)
In-Reply-To: <CAJJ6jxt-47saW=B260j0v_Gdt-dwb4YepRZTWQ-nYfLBGQUT=w@mail.gmail.com>

On 17-02-07 10:32:16, Steve Calfee wrote:
> On Mon, Feb 6, 2017 at 4:51 AM, Petko Manolov <petkan@nucleusys.com> wrote:
> > On 17-02-06 09:28:22, Greg KH wrote:
> >> On Mon, Feb 06, 2017 at 10:14:44AM +0200, Petko Manolov wrote:
> >> > On 17-02-05 01:30:39, Greg KH wrote:
> >> > > On Sat, Feb 04, 2017 at 04:56:03PM +0000, Ben Hutchings wrote:
> >> > > > Allocating USB buffers on the stack is not portable, and no longer works
> >> > > > on x86_64 (with VMAP_STACK enabled as per default).
> >> > >
> >> > > It's never worked on other platforms, so these should go to the stable
> >> > > releases please.
> >> >
> >> > As far as i know both drivers works fine on other platforms, though I only
> >> > tested it on arm and mipsel. ;)
> >>
> >> It all depends on the arm and mips platforms, the ones that can not DMA 
> >> from stack memory are the ones that would always fail here (since the 2.2 
> >> kernel days).
> >
> > Seems like most modern SOCs have decent DMA controllers.
> >
> 
> The real problem is not DMA exactly, it is cache coherency.
> 
> X86 has a coherent cache and all the cpu cores watch DMA transfers and keep 
> the cpu caches up to date.

Yep, these cpus are more user friendly.

> Most ARMs and MIPS processors have incoherent cache, so DMA can change memory 
> without the CPU cache updates. CPU cache view of what is in memory can be 
> different from what was DMAed in, this makes failures very hard to detect, 
> reproduce and racy.

Except for a very few purposes (like framebuffer memory) one should be crazy to 
use anything but kseg1 for accessing the peripherals.  One of the real problems 
here is the 512MB limit of the uncached segment.  While the DMA controller can 
typically access all available RAM you'll run into the issues that you describe 
with more than that amount of memory.

MIPS like doing things small and simple.  Everybody knows that software can 
compensate for hardware omissions. ;)

> So all DMA buffers should always be separate allocations from the stack AND 
> not be embedded in structs. Memory allocations are always at least cache line 
> aligned, so coherency is not a problem.

I do agree.


cheers,
Petko

  reply	other threads:[~2017-02-08  7:58 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-04 16:54 [PATCH net 0/4] Fix on-stack USB buffers Ben Hutchings
2017-02-04 16:56 ` [PATCH net 1/4] pegasus: Use heap buffers for all register access Ben Hutchings
2017-02-05  0:30   ` Greg KH
2017-02-06  8:14     ` Petko Manolov
2017-02-06  8:28       ` Greg KH
2017-02-06 12:51         ` Petko Manolov
2017-02-06 13:21           ` Johan Hovold
2017-02-06 13:32             ` Johan Hovold
2017-02-06 13:46               ` Johan Hovold
2017-02-07 10:24                 ` Petko Manolov
2017-02-07 10:45                   ` Greg KH
     [not found]                     ` <20170207104506.GB32583-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2017-02-07 12:50                       ` Petko Manolov
2017-02-06 13:30           ` David Laight
2017-02-07 18:32           ` Steve Calfee
2017-02-08  7:57             ` Petko Manolov [this message]
2017-02-04 16:56 ` [PATCH net 2/4] rtl8150: " Ben Hutchings
2017-02-06  8:10   ` Petko Manolov
     [not found]   ` <20170204165631.GW3442-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
2017-02-06 16:09     ` David Laight
2017-02-06 16:25       ` Ben Hutchings
2017-02-07 10:34         ` Petko Manolov
2017-02-07 10:51           ` Greg KH
2017-02-07 11:56             ` David Laight
     [not found]               ` <063D6719AE5E284EB5DD2968C1650D6DB027DB75-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
2017-02-07 12:42                 ` 'Greg KH'
2017-02-07 12:53             ` Petko Manolov
2017-02-07 13:01               ` Greg KH
2017-02-07 13:20                 ` Petko Manolov
2017-02-07 14:14                   ` David Laight
2017-02-07 14:52                     ` Petko Manolov
     [not found] ` <20170204165451.GU3442-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
2017-02-04 16:56   ` [PATCH net 3/4] catc: Combine failure cleanup code in catc_probe() Ben Hutchings
2017-02-04 16:57 ` [PATCH net 4/4] catc: Use heap buffer for memory size test Ben Hutchings
2017-02-07 15:07 ` [PATCH net 0/4] Fix on-stack USB buffers David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170208075736.clhgooyed5rvr3ng@p310 \
    --to=petkan@nucleusys.com \
    --cc=ben@decadent.org.uk \
    --cc=greg@kroah.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=lisandro@debian.org \
    --cc=netdev@vger.kernel.org \
    --cc=stevecalfee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox