From: Andre Przywara <andre.przywara@arm.com>
To: "David S . Miller" <davem@davemloft.net>,
Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Cc: Michal Simek <michal.simek@xilinx.com>,
Robert Hancock <hancock@sedsystems.ca>,
netdev@vger.kernel.org, rmk+kernel@arm.linux.org.uk,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCH v2 04/14] net: axienet: Fix DMA descriptor cleanup path
Date: Mon, 9 Mar 2020 18:29:59 +0000 [thread overview]
Message-ID: <20200309182959.080fa773@donnerap.cambridge.arm.com> (raw)
In-Reply-To: <20200309181851.190164-5-andre.przywara@arm.com>
On Mon, 9 Mar 2020 18:18:41 +0000
Andre Przywara <andre.przywara@arm.com> wrote:
Hi Radhey,
you looked at this patch before, it was [PATCH 03/14] back then.
You ended up saying "Looks fine then.", but I didn't dare to convert this into a "Reviewed-by:" tag.
Just a hint that I didn't change anything, that might simplify the review.
Cheers,
Andre
> When axienet_dma_bd_init() bails out during the initialisation process,
> it might do so with parts of the structure already allocated and
> initialised, while other parts have not been touched yet. Before
> returning in this case, we call axienet_dma_bd_release(), which does not
> take care of this corner case.
> This is most obvious by the first loop happily dereferencing
> lp->rx_bd_v, which we actually check to be non NULL *afterwards*.
>
> Make sure we only unmap or free already allocated structures, by:
> - directly returning with -ENOMEM if nothing has been allocated at all
> - checking for lp->rx_bd_v to be non-NULL *before* using it
> - only unmapping allocated DMA RX regions
>
> This avoids NULL pointer dereferences when initialisation fails.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> .../net/ethernet/xilinx/xilinx_axienet_main.c | 43 ++++++++++++-------
> 1 file changed, 28 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 64f73533cabe..9903205d57ec 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -160,24 +160,37 @@ static void axienet_dma_bd_release(struct net_device *ndev)
> int i;
> struct axienet_local *lp = netdev_priv(ndev);
>
> + /* If we end up here, tx_bd_v must have been DMA allocated. */
> + dma_free_coherent(ndev->dev.parent,
> + sizeof(*lp->tx_bd_v) * lp->tx_bd_num,
> + lp->tx_bd_v,
> + lp->tx_bd_p);
> +
> + if (!lp->rx_bd_v)
> + return;
> +
> for (i = 0; i < lp->rx_bd_num; i++) {
> - dma_unmap_single(ndev->dev.parent, lp->rx_bd_v[i].phys,
> - lp->max_frm_size, DMA_FROM_DEVICE);
> + /* A NULL skb means this descriptor has not been initialised
> + * at all.
> + */
> + if (!lp->rx_bd_v[i].skb)
> + break;
> +
> dev_kfree_skb(lp->rx_bd_v[i].skb);
> - }
>
> - if (lp->rx_bd_v) {
> - dma_free_coherent(ndev->dev.parent,
> - sizeof(*lp->rx_bd_v) * lp->rx_bd_num,
> - lp->rx_bd_v,
> - lp->rx_bd_p);
> - }
> - if (lp->tx_bd_v) {
> - dma_free_coherent(ndev->dev.parent,
> - sizeof(*lp->tx_bd_v) * lp->tx_bd_num,
> - lp->tx_bd_v,
> - lp->tx_bd_p);
> + /* For each descriptor, we programmed cntrl with the (non-zero)
> + * descriptor size, after it had been successfully allocated.
> + * So a non-zero value in there means we need to unmap it.
> + */
> + if (lp->rx_bd_v[i].cntrl)
> + dma_unmap_single(ndev->dev.parent, lp->rx_bd_v[i].phys,
> + lp->max_frm_size, DMA_FROM_DEVICE);
> }
> +
> + dma_free_coherent(ndev->dev.parent,
> + sizeof(*lp->rx_bd_v) * lp->rx_bd_num,
> + lp->rx_bd_v,
> + lp->rx_bd_p);
> }
>
> /**
> @@ -207,7 +220,7 @@ static int axienet_dma_bd_init(struct net_device *ndev)
> sizeof(*lp->tx_bd_v) * lp->tx_bd_num,
> &lp->tx_bd_p, GFP_KERNEL);
> if (!lp->tx_bd_v)
> - goto out;
> + return -ENOMEM;
>
> lp->rx_bd_v = dma_alloc_coherent(ndev->dev.parent,
> sizeof(*lp->rx_bd_v) * lp->rx_bd_num,
next prev parent reply other threads:[~2020-03-09 18:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-09 18:18 [PATCH v2 00/14] net: axienet: Update error handling and add 64-bit DMA support Andre Przywara
2020-03-09 18:18 ` [PATCH v2 01/14] net: xilinx: temac: Relax Kconfig dependencies Andre Przywara
2020-03-10 11:55 ` Esben Haabendal
2020-03-09 18:18 ` [PATCH v2 02/14] net: axienet: Convert DMA error handler to a work queue Andre Przywara
2020-03-09 18:18 ` [PATCH v2 03/14] net: axienet: Propagate failure of DMA descriptor setup Andre Przywara
2020-03-09 18:18 ` [PATCH v2 04/14] net: axienet: Fix DMA descriptor cleanup path Andre Przywara
2020-03-09 18:29 ` Andre Przywara [this message]
2020-03-09 18:18 ` [PATCH v2 05/14] net: axienet: Improve DMA error handling Andre Przywara
2020-03-09 18:18 ` [PATCH v2 06/14] net: axienet: Factor out TX descriptor chain cleanup Andre Przywara
2020-03-10 0:48 ` David Miller
2020-03-09 18:18 ` [PATCH v2 07/14] net: axienet: Check for DMA mapping errors Andre Przywara
2020-03-09 18:18 ` [PATCH v2 08/14] net: axienet: Mark eth_irq as optional Andre Przywara
2020-03-09 18:18 ` [PATCH v2 09/14] net: axienet: Drop MDIO interrupt registers from ethtools dump Andre Przywara
2020-03-09 18:18 ` [PATCH v2 10/14] net: axienet: Add mii-tool support Andre Przywara
2020-03-09 18:18 ` [PATCH v2 11/14] net: axienet: Wrap DMA pointer writes to prepare for 64 bit Andre Przywara
2020-03-09 18:18 ` [PATCH v2 12/14] net: axienet: Upgrade descriptors to hold 64-bit addresses Andre Przywara
2020-03-09 18:46 ` Robert Hancock
2020-03-10 9:35 ` Andre Przywara
2020-03-09 18:18 ` [PATCH v2 13/14] net: axienet: Autodetect 64-bit DMA capability Andre Przywara
2020-03-09 18:18 ` [PATCH v2 14/14] net: axienet: Allow DMA to beyond 4GB Andre Przywara
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=20200309182959.080fa773@donnerap.cambridge.arm.com \
--to=andre.przywara@arm.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=hancock@sedsystems.ca \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@xilinx.com \
--cc=netdev@vger.kernel.org \
--cc=radhey.shyam.pandey@xilinx.com \
--cc=rmk+kernel@arm.linux.org.uk \
/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