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]

Date:   Thu, 13 Apr 2023 20:07:04 +0300
From:   Leon Romanovsky <leon@...nel.org>
To:     Jakub Kicinski <kuba@...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, Apr 13, 2023 at 09:55:09AM -0700, Jakub Kicinski wrote:
> 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.

I don't disagree with you either, just have a feeling that proposed
behaviour is wrong.

Thanks