All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Shinas Rasheed <srasheed@marvell.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Haseeb Gani <hgani@marvell.com>,
	Vimlesh Kumar <vimleshk@marvell.com>,
	Sathesh B Edara <sedara@marvell.com>,
	"egallen@redhat.com" <egallen@redhat.com>,
	"mschmidt@redhat.com" <mschmidt@redhat.com>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"horms@kernel.org" <horms@kernel.org>,
	"wizhao@redhat.com" <wizhao@redhat.com>,
	"kheib@redhat.com" <kheib@redhat.com>,
	"konguyen@redhat.com" <konguyen@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Veerasenareddy Burru <vburru@marvell.com>,
	Satananda Burla <sburla@marvell.com>,
	Shannon Nelson <shannon.nelson@amd.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Joshua Hay <joshua.a.hay@intel.com>,
	Rahul Rameshbabu <rrameshbabu@nvidia.com>,
	Brett Creeley <brett.creeley@amd.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Jacob Keller <jacob.e.keller@intel.com>
Subject: Re: [EXT] Re: [PATCH net-next v5 1/8] octeon_ep_vf: Add driver framework and device initialization
Date: Tue, 6 Feb 2024 07:21:14 -0800	[thread overview]
Message-ID: <20240206072114.244738a9@kernel.org> (raw)
In-Reply-To: <PH0PR18MB473460118D0FC68BE4B3BC45C7462@PH0PR18MB4734.namprd18.prod.outlook.com>

On Tue, 6 Feb 2024 07:42:12 +0000 Shinas Rasheed wrote:
> > > We do cancel_work_sync in octep_vf_remove function.  
> > 
> > But the device is still registered, so the timeout can happen after you
> > cancel but before you unregister.  
> 
> There is rtnl_lock inside octep_vf_tx_timeout_task (the work task
> function), which can protect from unregister_netdev, for such cases
> (code snippet for quick reference below):
> 
> static void octep_vf_tx_timeout_task(struct work_struct *work)
> {
>         struct octep_vf_device *oct = container_of(work, struct octep_vf_device, tx_timeout_task);
>         struct net_device *netdev = oct->netdev;
> 
>         rtnl_lock();
>         if (netif_running(netdev)) {
>                 octep_vf_stop(netdev);
>                 octep_vf_open(netdev);
>         }
>         rtnl_unlock();
> }
> 
> I hope this takes care of it? Please let me know if my thought
> process feels wrong. Thanks!

The problem I see is that if the queue is somehow overloaded or delayed
there can be a race where we cancel, then timeout happens, work doesn't
run for a while, and we free the netdev. So what I'm suggesting is -
hold a reference on the netdevice. That way you can be sure it doesn't
get freed and you can depend on the rtnl+netif_running() doing its job.

  reply	other threads:[~2024-02-06 15:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-29  5:02 [PATCH net-next v5 0/8] add octeon_ep_vf driver Shinas Rasheed
2024-01-29  5:02 ` [PATCH net-next v5 1/8] octeon_ep_vf: Add driver framework and device initialization Shinas Rasheed
2024-02-01  0:14   ` Jakub Kicinski
2024-02-03  5:35     ` [EXT] " Shinas Rasheed
2024-02-05 23:44       ` Jakub Kicinski
2024-02-06  7:42         ` Shinas Rasheed
2024-02-06 15:21           ` Jakub Kicinski [this message]
2024-01-29  5:02 ` [PATCH net-next v5 2/8] octeon_ep_vf: add hardware configuration APIs Shinas Rasheed
2024-01-29  5:02 ` [PATCH net-next v5 3/8] octeon_ep_vf: add VF-PF mailbox communication Shinas Rasheed
2024-01-29  5:02 ` [PATCH net-next v5 4/8] octeon_ep_vf: add Tx/Rx ring resource setup and cleanup Shinas Rasheed
2024-01-29  5:02 ` [PATCH net-next v5 5/8] octeon_ep_vf: add support for ndo ops Shinas Rasheed
2024-01-29  5:02 ` [PATCH net-next v5 6/8] octeon_ep_vf: add Tx/Rx processing and interrupt support Shinas Rasheed
2024-01-29  5:02 ` [PATCH net-next v5 7/8] octeon_ep_vf: add ethtool support Shinas Rasheed
2024-01-29  5:02 ` [PATCH net-next v5 8/8] octeon_ep_vf: update MAINTAINERS Shinas Rasheed

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=20240206072114.244738a9@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=brett.creeley@amd.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=egallen@redhat.com \
    --cc=hgani@marvell.com \
    --cc=horms@kernel.org \
    --cc=jacob.e.keller@intel.com \
    --cc=joshua.a.hay@intel.com \
    --cc=kheib@redhat.com \
    --cc=konguyen@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mschmidt@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rrameshbabu@nvidia.com \
    --cc=sburla@marvell.com \
    --cc=sedara@marvell.com \
    --cc=shannon.nelson@amd.com \
    --cc=srasheed@marvell.com \
    --cc=vburru@marvell.com \
    --cc=vimleshk@marvell.com \
    --cc=wizhao@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.