netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"peppe.cavallaro@st.com" <peppe.cavallaro@st.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"m.szyprowski@samsung.com" <m.szyprowski@samsung.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"arc-linux-dev@synopsys.com" <arc-linux-dev@synopsys.com>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>
Subject: Re: [arc-linux-dev] [PATCH] stmmac: explicitly zero des0 & des1 on init
Date: Mon, 22 Jun 2015 14:04:11 +0530	[thread overview]
Message-ID: <5587C883.9080304@synopsys.com> (raw)
In-Reply-To: <1434960510.4269.25.camel@synopsys.com>

On Monday 22 June 2015 01:38 PM, Alexey Brodkin wrote:
> Hi all,
> 
> On Wed, 2015-06-17 at 07:03 +0000, Vineet Gupta wrote:
> +CC linux-arch, linux-mm, Arnd and Marek
> 
> On Tuesday 16 June 2015 11:11 PM, Alexey Brodkin wrote:
> 
> 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@synopsys.com><mailto:abrodkin@synopsys.com>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com><mailto:peppe.cavallaro@st.com>
> Cc: arc-linux-dev@synopsys.com<mailto:arc-linux-dev@synopsys.com>
> Cc: linux-kernel@vger.kernel.org<mailto:linux-kernel@vger.kernel.org>
> Cc: stable@vger.kernel.org<mailto:stable@vger.kernel.org>
> 
> FWIW, this was causing sporadic/random networking flakiness on ARC SDP platform (scheduled for upstream inclusion in next window)
> 
> This also leads to an interesting question - should arch/*/dma_alloc_coherent() and friends unconditionally zero out memory (vs. the current semantics of letting only doing it based on gfp, as requested by driver). This is the second instance we ran into stale descriptor memory, the first one was in dw_mmc driver which was recently fixed in upstream as well (although debugged independently by Alexey and using the upstream fix)
> 
> http://www.spinics.net/lists/linux-mmc/msg31600.html
> 
> The pros is better out of box experience (despite buggy drivers) while the cons are they remain broken and perhaps increased boot time due to extra memzero....
> 
> Probably if we already have dma_zalloc_coherent() that does explicit zeroing of returned memory then there's no need to do implicit zeroing in dma_alloc_coherent()?


The question is, when drivers don't have dma_zalloc_coherent() - meaning they
don't pass __GFP_ZERO, which causes these random issues, do we need to be more
conservative in arch code (ARC at least is) or do we need to debug and fix these
drivers - one by one.

FWIW, ARC needs to fix __GFP_ZERO case, since we are doing memzero twice.

-Vineet

  reply	other threads:[~2015-06-22  8:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-16 17:40 [PATCH] stmmac: explicitly zero des0 & des1 on init Alexey Brodkin
2015-06-17  7:03 ` [arc-linux-dev] " Vineet Gupta
2015-06-22  8:08   ` Alexey Brodkin
2015-06-22  8:34     ` Vineet Gupta [this message]
2015-06-21 16:29 ` David Miller
2015-06-22  6:43   ` Alexey Brodkin
2015-06-23 15:04     ` Alexey Brodkin
2015-06-24  7:18       ` David Miller
2015-06-24  8:07         ` [PATCH v2] stmmac: troubleshoot unexpected bits in des0 & des1 Alexey Brodkin
2015-06-24  8:44           ` David Miller
2015-06-24  8:36             ` Alexey Brodkin

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=5587C883.9080304@synopsys.com \
    --to=vineet.gupta1@synopsys.com \
    --cc=Alexey.Brodkin@synopsys.com \
    --cc=akpm@linux-foundation.org \
    --cc=arc-linux-dev@synopsys.com \
    --cc=arnd@arndb.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.szyprowski@samsung.com \
    --cc=netdev@vger.kernel.org \
    --cc=peppe.cavallaro@st.com \
    --cc=stable@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).