netdev - Re: [net-next v5 05/15] devlink: Support get and set state of port function

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 PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

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

Date:   Wed, 16 Dec 2020 16:08:50 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Parav Pandit <parav@...dia.com>
Cc:     Saeed Mahameed <saeed@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jason Gunthorpe <jgg@...dia.com>,
        Leon Romanovsky <leonro@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        David Ahern <dsahern@...nel.org>,
        Jacob Keller <jacob.e.keller@...el.com>,
        Sridhar Samudrala <sridhar.samudrala@...el.com>,
        "david.m.ertman@...el.com" <david.m.ertman@...el.com>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "kiran.patil@...el.com" <kiran.patil@...el.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Jiri Pirko <jiri@...dia.com>, Vu Pham <vuhuong@...dia.com>,
        Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [net-next v5 05/15] devlink: Support get and set state of port
 function

On Wed, 16 Dec 2020 05:15:04 +0000 Parav Pandit wrote:
> > From: Jakub Kicinski <kuba@...nel.org>
> > Sent: Wednesday, December 16, 2020 6:08 AM
> > 
> > On Tue, 15 Dec 2020 01:03:48 -0800 Saeed Mahameed wrote:  
> > > From: Parav Pandit <parav@...dia.com>
> > >
> > > devlink port function can be in active or inactive state.
> > > Allow users to get and set port function's state.
> > >
> > > When the port function it activated, its operational state may change
> > > after a while when the device is created and driver binds to it.
> > > Similarly on deactivation flow.  
> > 
> > So what's the flow device should implement?
> > 
> > User requests deactivated, the device sends a notification to the driver
> > bound to the device. What if the driver ignores it?
> >  
> If driver ignores it, those devices are marked unusable for new allocation.
> Device becomes usable only after it has act on the event.

But the device remains fully operational?

So if I'm an admin who wants to unplug a misbehaving "entity"[1]
the deactivate is not gonna help me, it's just a graceful hint?
Is there no need for a forceful shutdown?

[1] refer to earlier email, IDK what entity is supposed to use this

> > > + * @DEVLINK_PORT_FUNCTION_OPSTATE_DETACHED: Driver is detached  
> > from the function of port; it is  
> > > + *					    safe to delete the port.
> > > + */
> > > +enum devlink_port_function_opstate {
> > > +	DEVLINK_PORT_FUNCTION_OPSTATE_DETACHED,  
> > 
> > The port function must be some Mellanox speak - for the second time - I
> > have no idea what it means. Please use meaningful names.
> >  
> It is not a Mellanox term.
> Port function object is the one that represents function behind this port.
> It is not a new term. Port function already exists in devlink whose operational state attribute is defined here.

I must have missed that in review. PCI functions can host multiple
ports. So "port function" does not compute for me. Can we drop the
"function"?