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:	Wed, 16 Apr 2008 08:43:25 +0100
From:	Gerrit Renker <gerrit@....abdn.ac.uk>
To:	Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
Cc:	Arnaldo Carvalho de Melo <acme@...hat.com>, dccp@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked
	version of Tomasz's patch set

Quoting Tomasz Grobelny:
| Dnia Tuesday 15 of April 2008, Gerrit Renker napisa?:
| > | > @@ -501,6 +519,8 @@ struct dccp_sock {
| > | >  	struct ccid			*dccps_hc_rx_ccid;
| > | >  	struct ccid			*dccps_hc_tx_ccid;
| > | >  	struct dccp_options_received	dccps_options_received;
| > | > +	__u8				dccps_qpolicy;
| > | > +	__u32				dccps_tx_qlen;
| > | >  	enum dccp_role			dccps_role:2;
| > | >  	__u8				dccps_hc_rx_insert_options:1;
| > | >  	__u8				dccps_hc_tx_insert_options:1;
| > |
| > | I know that currently none of the policies has any per-socket data. But
| > | if it had were should it go?
| >
| > I can't see anything wrong with putting everything into dccp_sock. To do it
| > well, we could consider inserting documentation such as "this section is
| > only for queueing policies" (as is done very well for struct tcp_sock).
| >
| Let me remind you your comment made on 18/03/2008 on dccp ml to my first 
| patch:
|  --- START --- 
| @@ -545,6 +549,8 @@ struct dccp_sock {
|         __u8                            dccps_hc_tx_insert_options:1;
|         __u8                            dccps_server_timewait:1;
|         struct timer_list               dccps_xmit_timer;
| +       struct queuing_policy           *dccps_policy;
| +       void                            *dccps_policy_data;
|  };
| 
| I think this should be just one field for the policy, and the
| policy_data can be an internal field of `struct queueing_policy'
| (compare with struct ackvec or struct ccid).
|  --- END --- 
| 
Hm, even after reading it again I still find that I don't like void* fields. It
may be a personal thing, but I think using void* as part of a field is bad (and
this was in an even earlier comment).

I think I understand your approach better now, after going through the
patches again.


| Ok, you are right. If before DCCP_LISTENING there is always DCCP_CLOSED then 
| there is no need to allow changing qpolicy in DCCP_LISTENING state.
| 
Yes, that's right -- the initial state is always DCCP_CLOSED, set in
dccp_init_sock().


The University of Aberdeen is a charity registered in Scotland, No SC013683.

--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ