[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <jcvsmfivr27bchhk2t2lt2l35ixjs2adaos6hqwfydpulq7gxm@5aprxim4vvoa>
Date: Wed, 10 Sep 2025 12:50:07 -0700
From: Breno Leitao <leitao@...ian.org>
To: Andre Carvalho <asantostc@...il.com>
Cc: Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Shuah Khan <shuah@...nel.org>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net-next 4/5] netconsole: resume previously deactivated
target
On Tue, Sep 09, 2025 at 10:12:15PM +0100, Andre Carvalho wrote:
> @@ -1460,6 +1493,10 @@ static int netconsole_netdev_event(struct notifier_block *this,
> stopped = true;
> }
> }
> + if (nt->state == STATE_DEACTIVATED && event == NETDEV_UP) {
> + if (!strncmp(nt->np.dev_name, dev->name, IFNAMSIZ))
Don't you need to check for dev_mac here as well?
> + schedule_work(&nt->resume_wq);
I would prefer to have the enablement done inline here, instead of
scheduling a task.
It will be safer, given no one else is traversing the list and
accessing the element, given you have the target_list_lock in
netconsole_netdev_event, but, you don't have it in the resume_wq.
Given that we don't have a lock per target, target_list_lock is the
current lock protecting any simultaneous modification to the targets.
Powered by blists - more mailing lists