netdev - Re: [PATCH v9 net-next 13/14] pds_core: publish events to the clients

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230413095509.7f15e22c@kernel.org>
Date:   Thu, 13 Apr 2023 09:55:09 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     Shannon Nelson <shannon.nelson@....com>, brett.creeley@....com,
        davem@...emloft.net, netdev@...r.kernel.org, drivers@...sando.io,
        jiri@...nulli.us
Subject: Re: [PATCH v9 net-next 13/14] pds_core: publish events to the
 clients

On Thu, 13 Apr 2023 19:44:34 +0300 Leon Romanovsky wrote:
> > > I don't think that it is safe behaviour from user POV. If FW resets
> > > itself under the hood, how can client be sure that nothing changes
> > > in its operation? Once FW reset occurs, it is much safer for the clients
> > > to reconfigure everything.  
> > 
> > What's the argument exactly? We do have async resets including in mlx5,
> > grep for enable_remote_dev_reset  
> 
> I think that it is different. I'm complaining that during FW reset,
> auxiliary devices are not recreated and continue to be connected to
> physical device with a hope that everything will continue to work from
> kernel and FW perspective.
> 
> It is different from enable_remote_dev_reset, where someone externally
> resets device which will trigger mlx5_device_rescan() routine through
> mlx5_unload_one->mlx5_load_one sequence.

Hm, my memory may be incorrect and I didn't look at the code but 
I thought that knob came from the "hit-less upgrade" effort.
And for "hit-less upgrade" not respawning the devices was the whole
point.

Which is not to disagree with you. What I'm trying to get at is that
there are different types of reset which deserve different treatment.