netdev - Re: [net-next PATCH] net: dcb: add CEE notify calls

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:	Mon, 23 Apr 2012 06:36:40 -0700
From:	John Fastabend <john.r.fastabend@...el.com>
To:	Shmulik Ravid <shmulikr@...adcom.com>
CC:	davem@...emloft.net, netdev@...r.kernel.org, eilong@...adcom.com,
	amirv@....mellanox.co.il
Subject: Re: [net-next PATCH] net: dcb: add CEE notify calls

On 4/23/2012 5:51 AM, Shmulik Ravid wrote:
>> Signed-off-by: John Fastabend <john.r.fastabend@...el.com>
>> ---
>>
>>  net/dcb/dcbnl.c |    2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
>> index 8dfa1da..656c7c7 100644
>> --- a/net/dcb/dcbnl.c
>> +++ b/net/dcb/dcbnl.c
>> @@ -704,6 +704,7 @@ static int dcbnl_setapp(struct net_device *netdev, struct nlattr **tb,
>>  
>>  	ret = dcbnl_reply(err, RTM_SETDCB, DCB_CMD_SAPP, DCB_ATTR_APP,
>>  			  pid, seq, flags);
>> +	dcbnl_cee_notify(netdev, RTM_SETDCB, DCB_CMD_SAPP, seq, 0);
>>  out:
>>  	return ret;
>>  }
>> @@ -936,6 +937,7 @@ static int dcbnl_setall(struct net_device *netdev, struct nlattr **tb,
>>  
>>  	ret = dcbnl_reply(netdev->dcbnl_ops->setall(netdev), RTM_SETDCB,
>>  	                  DCB_CMD_SET_ALL, DCB_ATTR_SET_ALL, pid, seq, flags);
>> +	dcbnl_cee_notify(netdev, RTM_SETDCB, DCB_CMD_SET_ALL, seq, 0);
>>  
>>  	return ret;
>>  }
>>
> 
> In case of a FW DCBx agent these notification could be a bit confusing.
> In this case, the dcbnl_setxxx operations are used to set the initial
> negotiation parameters. dcbnl_setall triggers the negotiation and some
> time after that the FW DCBx agent driver should send a notification with
> the newly negotiated values. The notifications sent form within the set
> operations will return the current negotiated values which may very soon
> change. If we want to keep the user mode code simple and unified maybe
> we should send these notifications only if the DCBx agent is host based.
> 
> Shmulik 
> 

No. We want all the firmware agents and host based agents to look the
same from the application. The situation you described is exactly the
same for user space as in firmware. The DCBx state machine starts and may
call dcbnl_setxxx with initial (local) values. At some later point these
may change (possibly because of negotiation with a peer) and we need to
call dcbnl_setxxx again.

I don't see how this complicates any user mode code? Presumably the agent
is listening to DCBx events because it really wants to know the current
state of DCBx. It seems to me skipping notifications will actually cause
more issues this results in the hardware being in some state that did not
trigger any events and the agent will now be out of sync. This is the
problem I am trying to solve.

btw with this patch we can remove the notify calls in bnx2x.

.John
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html