Received: by 10.213.65.68 with SMTP id h4csp921680imn; Tue, 27 Mar 2018 11:14:26 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/CM+b3pJYS3y3HuPA1f1De7ljN8yn41aMzzNV2IhVp+OoNU9RnGF+97aCND6sJAHf+HoRd X-Received: by 10.99.97.130 with SMTP id v124mr216734pgb.351.1522174466149; Tue, 27 Mar 2018 11:14:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522174466; cv=none; d=google.com; s=arc-20160816; b=iB7DRo9v1Ro/qUxvLP0o69oYsKpqys9GguOnNPdQnKEn/XioewblgNjLn5HJgKDxlH 6M2ID89ivPHJDyU9yQfdgLu8DcHJzzVydMt+FZs1hVSD2ldOV0syW72ax04tdteEw6Re hFtOGsehU9f7X1PqLLOz6HpKP/axqC0Um2XxG0VzzBIfiVcAqESsTU5ITtUfquyFbYcj 3zNOsdcMfu0LUzLdlMVY7MNkqsEvK3huKyrpH/urtoQMDiFh+6imk3QR//3NJtVV52j3 n5Z1yWjgXu3l7xKa5+w1s051eOfk+b3lOR3atKaOTf6LnnL2lfOxplQPe2euQXTOEIwf lpog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=U2VJ41BhpZBZ0CywaGRs2sJXQuqfCx1qB11NTRVc6c4=; b=VycQ5DoetHIGiTbk10SWwNJawVfDvVcvxP5eZ7Bm0GVAaHW1h1TRUryHYPCiHDKVAc rSvFW4hovIHpQ3iNhHZY8HTjVdLdQgC7voJWLKKGzVDFvj1fIxRwkjGDaJLSGO5O3K3Z 82mVymcxQwnYCNzJrHsNWBLfrFihOpycY+wvT+WOuCAj/o3MuZaDmuGcfvWDy28k9HXW DJVIv5GdUNwtIA13y2XFclKvaoOrW3aA2n/tq1XGN8lNIBeO+bp6eRRFb70d3PS4YZbN MJFsP7SiwiH+mIW6PpBftw5oL3w43OLpW9P7wUGS3DTy2cryyps8N2XqOhsD15tb66ok nbGQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SXC+1PDH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r9si1286182pfg.8.2018.03.27.11.14.10; Tue, 27 Mar 2018 11:14:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=SXC+1PDH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752462AbeC0SLg (ORCPT + 99 others); Tue, 27 Mar 2018 14:11:36 -0400 Received: from mail-qk0-f179.google.com ([209.85.220.179]:36342 "EHLO mail-qk0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750948AbeC0SLe (ORCPT ); Tue, 27 Mar 2018 14:11:34 -0400 Received: by mail-qk0-f179.google.com with SMTP id o205so11643907qke.3; Tue, 27 Mar 2018 11:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U2VJ41BhpZBZ0CywaGRs2sJXQuqfCx1qB11NTRVc6c4=; b=SXC+1PDHWmjt7iHG/KroBzkufy/Yi4nw+Ot8DlL+MNNYzECkLBTWdkia9Gb6Y2LUO2 dCiBCVSPutQXrxxSv1Tvm6Mg6Ws3QFyLXFp48k20e3rnsgfUgTlZM2ounGgWtYaUm8CC TxjSREBYXLH/Al+TOHaMbcxMBO/BvjUR+bR4yIwH5wx9W5IK6732f7HSSfvp4W4pjGJs 1UAJ9QXT0e/Yjw9B3e2xgKrZBHgrEzDyhlm+ROaOy6q+T3HZbYtaqVfXaxjE/OMYlMa6 M55W5N3eXWnB/u3rMufIbbJQkMe0QAnOOhO8Fkrarc1kXr+BSPVkZJIe/roSYEPSzDpq jTkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U2VJ41BhpZBZ0CywaGRs2sJXQuqfCx1qB11NTRVc6c4=; b=kyWQ0sjeVGm2rJDHtlr7IVnvlAqut4IF3a90o0a0pI+qC12P7M6mWGrHe+BK+WNZAS 9MyYC3MorfhV3RQOO/P66R4bCA2yXMeRtxFsLrCGfoC4dmZI/xvikE5hThN98osApnGY JTET1eAkGujH0rBluvSHTUC1zcjQIh+WG4DFkTQowN4eN2K7hDzhBnuIkVwUC2CCHmso 7yDrhDw2B1YBoalPhWr3wKYn+KjLM1FqCCFsUtYNXh/uto73wYSBa56REJD8evV+gMUU edCeYTBtZKHhsY9UolHCskbyig8oPLgppb3RTjK4A9pLasuhahiq2nn7HUjyDufC0IZk q2pA== X-Gm-Message-State: AElRT7HcnWgSHBHb7xt+DXOgX5eQW1S2XcSnTPrTuZyd+BEY5g4uz8D+ RMQVouC8qZJhcDAHHLyJbL3cHIzg2pnVy3/Lik8= X-Received: by 10.55.195.92 with SMTP id a89mr538419qkj.33.1522174293382; Tue, 27 Mar 2018 11:11:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.137.74 with HTTP; Tue, 27 Mar 2018 11:11:32 -0700 (PDT) In-Reply-To: <1522170774.2593.9.camel@synopsys.com> References: <1522170774.2593.9.camel@synopsys.com> From: Andy Shevchenko Date: Tue, 27 Mar 2018 21:11:32 +0300 Message-ID: Subject: Re: dma-mapping: clearing GFP_ZERO flag caused crashes of Ethernet on arc/hsdk board. To: Evgeniy Didin Cc: "dmaengine@vger.kernel.org" , "hch@lst.de" , "iommu@lists.linux-foundation.org" , Eugeniy Paltsev , "linux-kernel@vger.kernel.org" , Alexey Brodkin , "jesper.nilsson@axis.com" , "geert@linux-m68k.org" , "linux-snps-arc@lists.infradead.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 27, 2018 at 8:12 PM, Evgeniy Didin wrote: > Hello, > > After commit 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in common code") we noticed problems with Ethernet controller on one of our platforms (namely ARC HSDK). > I > n particular we see that removal of __GFP_ZERO flag in function dma_alloc_attrs() was the culprit because in our implementation of arc_dma_alloc() we only allocate zeroed pages if > that flag is explicitly set by the caller. Now with unconditional removal of that flag in dma_alloc_attrs() we allocate non-zeroed pages and that seem to cause problems. > > From > mentioned commit message I may conclude that architectural code is supposed to always allocate zeroed pages but I cannot find any requirement of that in kernel's documentation. > Coul > d you please point me to that requirement if that exists at all, then we'll implement a fix in our arch code like that: Can you elaborate what driver is in use? stmmac with dwmac-anarion? If so, this driver (w/o anarion parts, which I believe doesn't have anything to do with this) is widely used on other platforms. We have to see a lot of reports, though only one so far? The logical question is why? Another question why caller can't ask for zero pages explicitly? P.S. Current kernel code shows only 3 use cases of GFP_ZERO. It seems arm64 has something similar in mind. > --------------------->8--------------------- > diff --git > a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c > index 1dcc404b5aec..c92e518413aa 100644 > --- a/arch/arc/mm/dma.c > +++ b/arch/arc/mm/dma.c > @@ -30,7 +30,7 @@ static void *arc_dma_alloc(struct > device *dev, size_t size, > void *kvaddr; > int need_coh = 1, need_kvaddr = 0; > > - page = alloc_pages(gfp, order); > + page = alloc_pages(gfp | __GFP_ZERO, order); > > if (!page) > return NULL; > --------------------->8--------------------- > > Best regards, > Evgeniy Didin -- With Best Regards, Andy Shevchenko