All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Yongjun <yjwei@cn.fujitsu.com>
To: dccp@vger.kernel.org
Subject: Re: v3 [PATCH 1/1] dccp: Process incoming Change	feature-negotiation
Date: Wed, 03 Sep 2008 06:03:23 +0000	[thread overview]
Message-ID: <48BE28AB.8040905@cn.fujitsu.com> (raw)
In-Reply-To: <20080823105647.GA15928@gerrit.erg.abdn.ac.uk>

Gerrit Renker wrote:
>>> +	/*
>>> +	 *	Unidirectional/simultaneous negotiation of SP features (6.3.1)
>>> +	 */
>>> +	entry = dccp_feat_list_lookup(fn, feat, local);
>>> +	if (entry = NULL) {
>>> +		if (!dccp_feat_sp_list_ok(feat, val, len))
>>> +			goto unknown_feature_or_value;
>>>   
>>>       
>> Check for sp feat list should before code "entry =  
>> dccp_feat_list_lookup(fn, feat, local);",
>> here only check for features not register by local endpoint, if the  
>> feature is registed, the validity check is missing?
>>
>>     
> +
> No, in this case the validity check is performed already as part of the socket
> registration routines - which in turn end up calling dccp_feat_sp_list_ok.  
> If a user tries to register invalid SP values on the socket, the attempt
> will fail with EINVAL. If the user does not register values, the feature
> defaults (6.4) are used, which are valid by definition.
> The host is conservative in what it allows to send out.
>   

The socket registration routines check the feature values local set, but 
this place is check
the features we *received* from other endpoints.

I agree with you here do not need chec as your other mail said:
RFC4340 6.6.8
Note that server-priority features do not have value limitations, since
unknown values are handled as a matter of course.

May be this check "if (!dccp_feat_sp_list_ok(feat, val, len))" is too 
strictly for known
sp features but not registed by socket.



WARNING: multiple messages have this Message-ID (diff)
From: Wei Yongjun <yjwei@cn.fujitsu.com>
To: Gerrit Renker <gerrit@erg.abdn.ac.uk>,
	Wei Yongjun <yjwei@cn.fujitsu.com>,
	dccp@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: v3 [PATCH 1/1] dccp: Process incoming Change	feature-negotiation options
Date: Wed, 03 Sep 2008 14:03:23 +0800	[thread overview]
Message-ID: <48BE28AB.8040905@cn.fujitsu.com> (raw)
In-Reply-To: <20080903042709.GB4105@gerrit.erg.abdn.ac.uk>

Gerrit Renker wrote:
>>> +	/*
>>> +	 *	Unidirectional/simultaneous negotiation of SP features (6.3.1)
>>> +	 */
>>> +	entry = dccp_feat_list_lookup(fn, feat, local);
>>> +	if (entry == NULL) {
>>> +		if (!dccp_feat_sp_list_ok(feat, val, len))
>>> +			goto unknown_feature_or_value;
>>>   
>>>       
>> Check for sp feat list should before code "entry =  
>> dccp_feat_list_lookup(fn, feat, local);",
>> here only check for features not register by local endpoint, if the  
>> feature is registed, the validity check is missing?
>>
>>     
> +
> No, in this case the validity check is performed already as part of the socket
> registration routines - which in turn end up calling dccp_feat_sp_list_ok.  
> If a user tries to register invalid SP values on the socket, the attempt
> will fail with EINVAL. If the user does not register values, the feature
> defaults (6.4) are used, which are valid by definition.
> The host is conservative in what it allows to send out.
>   

The socket registration routines check the feature values local set, but 
this place is check
the features we *received* from other endpoints.

I agree with you here do not need chec as your other mail said:
RFC4340 6.6.8
Note that server-priority features do not have value limitations, since
unknown values are handled as a matter of course.

May be this check "if (!dccp_feat_sp_list_ok(feat, val, len))" is too 
strictly for known
sp features but not registed by socket.



  parent reply	other threads:[~2008-09-03  6:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-23 10:56 v3 [PATCH 1/1] dccp: Process incoming Change feature-negotiation Gerrit Renker
2008-08-23 10:56 ` v3 [PATCH 1/1] dccp: Process incoming Change feature-negotiation options Gerrit Renker
2008-09-02  6:59 ` v3 [PATCH 1/1] dccp: Process incoming Change feature-negotiation Wei Yongjun
2008-09-02  6:59   ` v3 [PATCH 1/1] dccp: Process incoming Change feature-negotiation options Wei Yongjun
2008-09-03  4:27 ` v3 [PATCH 1/1] dccp: Process incoming Change Gerrit Renker
2008-09-03  4:27   ` v3 [PATCH 1/1] dccp: Process incoming Change feature-negotiation options Gerrit Renker
2008-09-03  6:03 ` Wei Yongjun [this message]
2008-09-03  6:03   ` Wei Yongjun
2008-09-03  8:24 ` v3 [PATCH 1/1] dccp: Process incoming Change Gerrit Renker
2008-09-03  8:24   ` v3 [PATCH 1/1] dccp: Process incoming Change feature-negotiation options Gerrit Renker
2008-09-03 12:27 ` v3 [PATCH 1/1] dccp: Process incoming Change feature-negotiation Eddie Kohler
2008-09-03 12:27   ` v3 [PATCH 1/1] dccp: Process incoming Change feature-negotiation options Eddie Kohler
2008-09-03 15:11 ` v3 [PATCH 1/1] dccp: Process incoming Change Gerrit Renker
2008-09-03 15:11   ` v3 [PATCH 1/1] dccp: Process incoming Change feature-negotiation options Gerrit Renker
2008-09-04  4:51 ` v3 [PATCH 1/1] dccp: Process incoming Change Gerrit Renker
2008-09-04  4:51   ` v3 [PATCH 1/1] dccp: Process incoming Change feature-negotiation options Gerrit Renker
2008-09-04 13:23 ` v3 [PATCH 1/1] dccp: Process incoming Change feature-negotiation Eddie Kohler
2008-09-04 13:23   ` v3 [PATCH 1/1] dccp: Process incoming Change feature-negotiation options Eddie Kohler
  -- strict thread matches above, loose matches on Subject: below --
2008-08-21 17:19 v2 [PATCH 3/3] " Gerrit Renker
2008-08-21 17:19 ` Gerrit Renker
2008-08-21 17:19 [PATCH 2/3] dccp: Fill in the Data fields when option processing encounters option errors Gerrit Renker
2008-08-21 17:19 ` Gerrit Renker
2008-08-21 17:19 [PATCH 1/3] dccp: Silently ignore options with nonsensical lengths Gerrit Renker
2008-08-21 17:19 ` Gerrit Renker
2008-08-21 17:19 [RFC/RFT] [PATCH 0/3] dccp: Updates for parsing header options Gerrit Renker
2008-08-21 17:19 ` Gerrit Renker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48BE28AB.8040905@cn.fujitsu.com \
    --to=yjwei@cn.fujitsu.com \
    --cc=dccp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.