public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Justin Lai <justinlai0215@realtek.com>
To: Simon Horman <horms@kernel.org>
Cc: Markus Elfring <Markus.Elfring@web.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	Hariprasad Kelam <hkelam@marvell.com>,
	Jiri Pirko <jiri@resnulli.us>,
	Larry Chiu <larry.chiu@realtek.com>,
	Ping-Ke Shih <pkshih@realtek.com>,
	Ratheesh Kannoth <rkannoth@marvell.com>
Subject: RE: [v20 02/13] rtase: Implement the .ndo_open function
Date: Tue, 18 Jun 2024 07:51:19 +0000	[thread overview]
Message-ID: <416da6e14d134caeaa4bfe29291f0eb2@realtek.com> (raw)
In-Reply-To: <20240617185956.GY8447@kernel.org>

> On Mon, Jun 17, 2024 at 01:28:51PM +0000, Justin Lai wrote:
> >
> > > >> How do you think about to increase the application of scope-based
> > > >> resource
> > > management?
> > > >> https://elixir.bootlin.com/linux/v6.10-rc3/source/include/linux/c
> > > >> lean
> > > >> up.h#L8
> > > >
> > > > Due to our tx and rx each having multiple queues that need to
> > > > allocate descriptors, if any one of the queues fails to allocate,
> > > > rtase_alloc_desc() will return an error. Therefore, using 'goto'
> > > > here rather than directly returning seems to be reasonable.
> > >
> > > Some goto chains can be replaced by further usage of advanced
> > > cleanup techniques, can't they?
> > >
> > > Regards,
> > > Markus
> >
> > rtase_alloc_desc() is used to allocate DMA memory.
> > I'd like to ask if it's better to keep our current method?
> 
> Hi Justin,
> 
> It may be the case that the techniques recently added by cleanup.h could be
> used here. But, OTOH, it is the case that using goto for unwinding errors is in
> keeping with current Networking driver best practices.
> 
> Regardless of the above, I would suggest that if an error occurs in
> rtase_alloc_desc() then it release any resources it has allocated. Assuming the
> elements of tp->tx_ring and tp->rx_ring are initialised to NULL when
> rtase_alloc_desc is called, it looks like that can be achieved by
> rtase_alloc_desc() calling rtase_free_desc().
> 
> Something like the following (completely untested!).
> Please also note that there is probably no need to call netdev_err on error, as
> the memory core should already log on error.
> 
> static int rtase_alloc_desc(struct rtase_private *tp) {
>         struct pci_dev *pdev = tp->pdev;
>         u32 i;
> 
>         /* rx and tx descriptors needs 256 bytes alignment.
>          * dma_alloc_coherent provides more.
>          */
>         for (i = 0; i < tp->func_tx_queue_num; i++) {
>                 tp->tx_ring[i].desc =
>                                 dma_alloc_coherent(&pdev->dev,
> 
> RTASE_TX_RING_DESC_SIZE,
> 
> &tp->tx_ring[i].phy_addr,
>                                                    GFP_KERNEL);
>                 if (!tp->tx_ring[i].desc)
>                         goto err;
>         }
> 
>         for (i = 0; i < tp->func_rx_queue_num; i++) {
>                 tp->rx_ring[i].desc =
>                                 dma_alloc_coherent(&pdev->dev,
> 
> RTASE_RX_RING_DESC_SIZE,
> 
> &tp->rx_ring[i].phy_addr,
>                                                    GFP_KERNEL);
>                 if (!tp->rx_ring[i].desc)
>                         goto err;
>                 }
>         }
> 
>         return 0;
> 
> err:
>         rtase_free_desc(tp)
>         return -ENOMEM;
> }
> 
> And then rtase_alloc_desc can be called like this in rtase_open():
> 
> static int rtase_open(struct net_device *dev) {
>         struct rtase_private *tp = netdev_priv(dev);
>         const struct pci_dev *pdev = tp->pdev;
>         struct rtase_int_vector *ivec;
>         u16 i = 0, j;
>         int ret;
> 
>         ivec = &tp->int_vector[0];
>         tp->rx_buf_sz = RTASE_RX_BUF_SIZE;
> 
>         ret = rtase_alloc_desc(tp);
>         if (ret)
>                 return ret;
> 
>         ret = rtase_init_ring(dev);
>         if (ret)
>                 goto err_free_all_allocated_mem;
> 
> ...
> 
> err_free_all_allocated_mem:
>         rtase_free_desc(tp);
> 
>         return ret;
> }
> 
> This is would be in keeping with my understanding of best practices for
> Networking drivers: that callers don't have to worry about cleaning up
> resources allocated by functions that return an error.
> 
> 
> I would also suggest reading Markus's advice with due care, as it is not always
> aligned with best practice for Networking code.

Hi Simon,
Thank you for your response. Based on your suggestion, if the descriptor
allocation of DMA memory fails, I will directly do error handling in
rtase_alloc_desc() using the 'goto' method. Moreover, in the error
handling section, I will call rtase_free_desc(tp) to free the already
allocated descriptor.


  parent reply	other threads:[~2024-06-18  7:51 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07  8:43 [PATCH net-next v20 00/13] Add Realtek automotive PCIe driver Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 01/13] rtase: Add pci table supported in this module Justin Lai
2024-06-13  9:01   ` Markus Elfring
2024-06-17  8:14     ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 02/13] rtase: Implement the .ndo_open function Justin Lai
2024-06-13  7:50   ` Markus Elfring
2024-06-17  9:25     ` Justin Lai
2024-06-17 10:07       ` [v20 " Markus Elfring
2024-06-17 13:28         ` Justin Lai
2024-06-17 18:59           ` Simon Horman
2024-06-17 20:22             ` Markus Elfring
2024-06-18  7:51             ` Justin Lai [this message]
     [not found]             ` <202406181007.45IA7eWxA3305754@rtits1.realtek.com.tw>
2024-06-18 11:01               ` Justin Lai
2024-06-18 11:30                 ` Markus Elfring
2024-06-07  8:43 ` [PATCH net-next v20 03/13] rtase: Implement the rtase_down function Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 04/13] rtase: Implement the interrupt routine and rtase_poll Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 05/13] rtase: Implement hardware configuration function Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 06/13] rtase: Implement .ndo_start_xmit function Justin Lai
2024-06-07  9:03   ` Hariprasad Kelam
2024-06-12  4:35     ` Justin Lai
2024-06-12 10:36       ` Hariprasad Kelam
2024-06-13  3:38         ` Justin Lai
2024-06-13  7:24           ` Hariprasad Kelam
2024-06-07 15:54   ` Ratheesh Kannoth
2024-06-12  4:20     ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 07/13] rtase: Implement a function to receive packets Justin Lai
2024-06-13  0:43   ` Jakub Kicinski
2024-06-17  6:44     ` Justin Lai
2024-06-17 15:02       ` Jakub Kicinski
2024-06-18  3:40         ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 08/13] rtase: Implement net_device_ops Justin Lai
2024-06-13  0:39   ` Jakub Kicinski
2024-06-13  3:16     ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 09/13] rtase: Implement pci_driver suspend and resume function Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 10/13] rtase: Implement ethtool function Justin Lai
2024-06-13  0:35   ` Jakub Kicinski
2024-06-17  6:54     ` Justin Lai
2024-06-17 14:07       ` Andrew Lunn
2024-06-18  9:56         ` Justin Lai
2024-06-17 15:10       ` Jakub Kicinski
2024-06-18  7:28         ` Justin Lai
2024-06-18 14:24           ` Jakub Kicinski
2024-06-19  3:40             ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 11/13] rtase: Add a Makefile in the rtase folder Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 12/13] realtek: Update the Makefile and Kconfig in the realtek folder Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 13/13] MAINTAINERS: Add the rtase ethernet driver entry Justin Lai

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=416da6e14d134caeaa4bfe29291f0eb2@realtek.com \
    --to=justinlai0215@realtek.com \
    --cc=Markus.Elfring@web.de \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkelam@marvell.com \
    --cc=horms@kernel.org \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=larry.chiu@realtek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pkshih@realtek.com \
    --cc=rkannoth@marvell.com \
    /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