Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: Guenter Roeck <groeck7@gmail.com>
Date:   Mon, 5 Apr 2021 19:22:00 -0700
From:   Guenter Roeck <linux@roeck-us.net>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
        akpm@linux-foundation.org, shuah@kernel.org, patches@kernelci.org,
        lkft-triage@lists.linaro.org, pavel@denx.de, jonathanh@nvidia.com,
        f.fainelli@gmail.com, stable@vger.kernel.org
Subject: Re: [PATCH 4.9 00/35] 4.9.265-rc1 review
Message-ID: <20210406022200.GA20578@roeck-us.net>
References: <20210405085018.871387942@linuxfoundation.org>
 <20210405175629.GB93485@roeck-us.net>
 <20210405235155.GA75187@roeck-us.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210405235155.GA75187@roeck-us.net>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Mon, Apr 05, 2021 at 04:51:55PM -0700, Guenter Roeck wrote:
> On Mon, Apr 05, 2021 at 10:56:29AM -0700, Guenter Roeck wrote:
> > On Mon, Apr 05, 2021 at 10:53:35AM +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.9.265 release.
> > > There are 35 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Wed, 07 Apr 2021 08:50:09 +0000.
> > > Anything received after that time might be too late.
> > > 
> > 
> > Build results:
> > 	total: 163 pass: 163 fail: 0
> > Qemu test results:
> > 	total: 383 pass: 382 fail: 1
> > Failed tests:
> > 	parisc:generic-32bit_defconfig:smp:net,pcnet:scsi[53C895A]:rootfs
> > 
> > In the failing test, the network interfcace instantiates but fails to get
> > an IP address. This is not a new problem but a new test. For some reason
> > it only happens with this specific network interface, this specific SCSI
> > controller, and with v4.9.y. No reason for concern; I'll try to track down
> > what is going on.
> > 
> 
> Interesting. The problem affects all kernels up to and including
> v4.19.y. Unlike I thought initially, the problem is not associated
> with the SCSI controller (that was coincidental) but with pcnet
> Ethernet interfaces. It has been fixed in the upstream kernel with
> commit 518a2f1925c3 ("dma-mapping: zero memory returned from
> dma_alloc_*"). This patch does not apply cleanly to any of the
> affected kernels. I backported part of it to v4.19.y and v4.9.y
> and confirmed that it fixes the problem in those branches.
> 
> Question is what we should do: try to backport 518a2f1925c3 to v4.19.y
> and earlier, or stop testing against this specific problem.
> 

Another update: The following code change fixes the problem as well.
Commit 518a2f1925c3 fixes it only as side effect since it clears
all DMA buffers.

diff --git a/drivers/net/ethernet/amd/pcnet32.c b/drivers/net/ethernet/amd/pcnet32.c
index c22bf52d3320..7a25ec8390e4 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -1967,7 +1967,7 @@ static int pcnet32_alloc_ring(struct net_device *dev, const char *name)
                return -ENOMEM;
        }

-       lp->rx_ring = pci_alloc_consistent(lp->pci_dev,
+       lp->rx_ring = pci_zalloc_consistent(lp->pci_dev,
                                           sizeof(struct pcnet32_rx_head) *
                                           lp->rx_ring_size,
                                           &lp->rx_ring_dma_addr);

I'll submit a patch implementing that; we'll see how it goes.

Thanks,
Guenter