[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1434955394.4269.6.camel@synopsys.com>
Date: Mon, 22 Jun 2015 06:43:15 +0000
From: Alexey Brodkin <Alexey.Brodkin@...opsys.com>
To: "davem@...emloft.net" <davem@...emloft.net>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"arc-linux-dev@...opsys.com" <arc-linux-dev@...opsys.com>,
"peppe.cavallaro@...com" <peppe.cavallaro@...com>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] stmmac: explicitly zero des0 & des1 on init
Hi David,
On Sun, 2015-06-21 at 09:29 -0700, David Miller wrote:
> From: Alexey Brodkin <Alexey.Brodkin@...opsys.com>
> Date: Tue, 16 Jun 2015 20:40:41 +0300
>
> > Current implementtion of descriptor init procedure only takes care
> > about
> > ownership flag. While it is perfectly possible to have underlying
> > memory
> > filled with garbage on boot or driver installation.
> >
> > And randomly set flags in non-zeroed des0 and des1 fields may lead
> > to
> > unpredictable behavior of the GMAC DMA block.
> >
> > Solution to this problem is as simple as explicit zeroing of both
> > des0
> > and des1 fields of all buffer descriptors.
> >
> > Signed-off-by: Alexey Brodkin <abrodkin@...opsys.com>
>
> If you need the memory zero initialized, use dma_zalloc_coherent().
Indeed usage of dma_zalloc_coherent() will resolve observed issue.
But since buffer descriptors are reused extensively I would say that
explicit zeroing of fields with flags is useful. Probably I need to add
this clarification in commit message.
And then if we do that explicit zeroing of flags and other fields which
hold data size and addresses of data buffer and the next descriptor in
chain are all get set later we may not care about allocation of zeroed
memory.
-Alexey--
To unsubscribe from this list: send the line "unsubscribe netdev" in
Powered by blists - more mailing lists