1. 29 1月, 2008 32 次提交
  2. 21 12月, 2007 1 次提交
  3. 20 11月, 2007 1 次提交
  4. 07 11月, 2007 2 次提交
  5. 24 10月, 2007 4 次提交
    • G
      [CCID2/3]: Initialisation assignments of 0 are redundant · 24c667db
      Gerrit Renker 提交于
      Assigning initial values of `0' is redundant when loading a new CCID structure,
      since in net/dccp/ccid.c the entire CCID structure is zeroed out prior to
      initialisation in ccid_new():
      
          	struct ccid {
          		struct ccid_operations *ccid_ops;
          		char		       ccid_priv[0];
          	};
      
          	// ...
          	if (rx) {
          		memset(ccid + 1, 0, ccid_ops->ccid_hc_rx_obj_size);
          		if (ccid->ccid_ops->ccid_hc_rx_init != NULL &&
          		    ccid->ccid_ops->ccid_hc_rx_init(ccid, sk) != 0)
          			goto out_free_ccid;
          	} else {
          		memset(ccid + 1, 0, ccid_ops->ccid_hc_tx_obj_size);
          		/* analogous to the rx case */
          	}
      
      This patch therefore removes the redundant assignments. Thanks to Arnaldo for
      the inspiration.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      24c667db
    • G
      [DCCP]: Unaligned pointer access · 76fd1e87
      Gerrit Renker 提交于
      This fixes `unaligned (read) access' errors of the type
      
      Kernel unaligned access at TPC[100f970c] dccp_parse_options+0x4f4/0x7e0 [dccp]
      Kernel unaligned access at TPC[1011f2e4] ccid3_hc_tx_parse_options+0x1ac/0x380 [dccp_ccid3]
      Kernel unaligned access at TPC[100f9898] dccp_parse_options+0x680/0x880 [dccp]
      
      by using the get_unaligned macro for parsing options.
      
      Commiter note: Preserved the sparse __be{16,32} annotations.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      76fd1e87
    • G
      [DCCP]: Convert Reset code into socket error number · d8ef2c29
      Gerrit Renker 提交于
      This adds support for converting the 11 currently defined Reset codes into system
      error numbers, which are stored in sk_err for further interpretation.
      
      This makes the externally visible API behaviour similar to TCP, since a client
      connecting to a non-existing port will experience ECONNREFUSED.
      
      * Code 0, Unspecified, is interpreted as non-error (0);
      * Code 1, Closed (normal termination), also maps into 0;
      * Code 2, Aborted, maps into "Connection reset by peer" (ECONNRESET);
      * Code 3, No Connection and
        Code 7, Connection Refused, map into "Connection refused" (ECONNREFUSED);
      * Code 4, Packet Error, maps into "No message of desired type" (ENOMSG);
      * Code 5, Option Error, maps into "Illegal byte sequence" (EILSEQ);
      * Code 6, Mandatory Error, maps into "Operation not supported on transport endpoint" (EOPNOTSUPP);
      * Code 8, Bad Service Code, maps into "Invalid request code" (EBADRQC);
      * Code 9, Too Busy, maps into "Too many users" (EUSERS);
      * Code 10, Bad Init Cookie, maps into "Invalid request descriptor" (EBADR);
      * Code 11, Aggression Penalty, maps into "Quota exceeded" (EDQUOT)
        which makes sense in terms of using more than the `fair share' of bandwidth.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d8ef2c29
    • G
      [DCCP]: One more exemption from full sequence number checks · 1238d087
      Gerrit Renker 提交于
      This fixes the following problem: client connects to peer which has no DCCP
      enabled or loaded; ICMP error messages ("Protocol Unavailable") can be seen
      on the wire, but the application hangs. Reason: ICMP packets don't get through
      to dccp_v4_err.
      
      When reporting errors, a sequence number check is made for the DCCP packet
      that had caused an ICMP error to arrive.
      Such checks can not be made if the socket is in state LISTEN, RESPOND (which
      in the implementation is the same as LISTEN), or REQUEST, since update_gsr()
      has not been called in these states, hence the sequence window is 0..0.
      
      This patch fixes the problem by adding the REQUEST state as another exemption
      to the window check. The error reporting now works as expected on connecting.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      1238d087