linux-kernel - RE: [EXT] Re: [PATCH net-next v3 2/4] octeon

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: <PH0PR18MB4734DDA8FB983018EB790B9FC78FA@PH0PR18MB4734.namprd18.prod.outlook.com>
Date:   Mon, 11 Dec 2023 15:39:31 +0000
From:   Shinas Rasheed <srasheed@...vell.com>
To:     Leon Romanovsky <leon@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Haseeb Gani <hgani@...vell.com>,
        Vimlesh Kumar <vimleshk@...vell.com>,
        "egallen@...hat.com" <egallen@...hat.com>,
        "mschmidt@...hat.com" <mschmidt@...hat.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "horms@...nel.org" <horms@...nel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "wizhao@...hat.com" <wizhao@...hat.com>,
        "kheib@...hat.com" <kheib@...hat.com>,
        "konguyen@...hat.com" <konguyen@...hat.com>,
        Veerasenareddy Burru <vburru@...vell.com>,
        Sathesh B Edara <sedara@...vell.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: RE: [EXT] Re: [PATCH net-next v3 2/4] octeon_ep: PF-VF mailbox
 version support

> > I'm afraid as to what else can be an alternative? The control net commands
> have to be decoded and passed by the PF driver for the VFs,
> > as only the PFs have access to talk to firmware directly. The VF drivers do
> not have an alternative way to query control net APIs, and may fail
> > if the control net APIs they have are not even recognized by the PF to
> decode them.
> >
> > Either VF commands which the PF can't support can be blocked at the
> source (by the equivalent PF-VF backward compatibility which will exist in VF
> drivers)
> > by this negotiation, or we have to let commands come through and fail
> them, leading to just redundancy in terms of running code. I don't see how
> this negotiation in
> > any way 'limit' the VF drivers.
> >
> > As you said, in essence the VF drivers will have to fallback to v0 for
> backward compatibility if the native host uses some old OS having older PF
> drivers. If not, the
> > commands would come and fail anyways at the PF. Either way, it's an error
> case and this negotiation is just to decide if we are going to allow letting such
> commands in.
> 
> I don't know what netdev maintainers will do with this code, I just
> pointed to this architecture/HW troublesome design.
> 
> Thanks

I understand, thanks for your scrutiny. As I understand, its a case for letting errors run its course by letting
unsupported commands in, or negotiate for a common version and stop earlier on control plane commands which the PF driver just doesn't know. 

Again, thanks for your constructive insight.