1. 21 4月, 2010 1 次提交
  2. 16 4月, 2010 1 次提交
  3. 12 4月, 2010 1 次提交
  4. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  5. 19 10月, 2009 1 次提交
    • E
      inet: rename some inet_sock fields · c720c7e8
      Eric Dumazet 提交于
      In order to have better cache layouts of struct sock (separate zones
      for rx/tx paths), we need this preliminary patch.
      
      Goal is to transfert fields used at lookup time in the first
      read-mostly cache line (inside struct sock_common) and move sk_refcnt
      to a separate cache line (only written by rx path)
      
      This patch adds inet_ prefix to daddr, rcv_saddr, dport, num, saddr,
      sport and id fields. This allows a future patch to define these
      fields as macros, like sk_refcnt, without name clashes.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c720c7e8
  6. 10 7月, 2009 1 次提交
    • J
      net: adding memory barrier to the poll and receive callbacks · a57de0b4
      Jiri Olsa 提交于
      Adding memory barrier after the poll_wait function, paired with
      receive callbacks. Adding fuctions sock_poll_wait and sk_has_sleeper
      to wrap the memory barrier.
      
      Without the memory barrier, following race can happen.
      The race fires, when following code paths meet, and the tp->rcv_nxt
      and __add_wait_queue updates stay in CPU caches.
      
      CPU1                         CPU2
      
      sys_select                   receive packet
        ...                        ...
        __add_wait_queue           update tp->rcv_nxt
        ...                        ...
        tp->rcv_nxt check          sock_def_readable
        ...                        {
        schedule                      ...
                                      if (sk->sk_sleep && waitqueue_active(sk->sk_sleep))
                                              wake_up_interruptible(sk->sk_sleep)
                                      ...
                                   }
      
      If there was no cache the code would work ok, since the wait_queue and
      rcv_nxt are opposit to each other.
      
      Meaning that once tp->rcv_nxt is updated by CPU2, the CPU1 either already
      passed the tp->rcv_nxt check and sleeps, or will get the new value for
      tp->rcv_nxt and will return with new data mask.
      In both cases the process (CPU1) is being added to the wait queue, so the
      waitqueue_active (CPU2) call cannot miss and will wake up CPU1.
      
      The bad case is when the __add_wait_queue changes done by CPU1 stay in its
      cache, and so does the tp->rcv_nxt update on CPU2 side.  The CPU1 will then
      endup calling schedule and sleep forever if there are no more data on the
      socket.
      
      Calls to poll_wait in following modules were ommited:
      	net/bluetooth/af_bluetooth.c
      	net/irda/af_irda.c
      	net/irda/irnet/irnet_ppp.c
      	net/mac80211/rc80211_pid_debugfs.c
      	net/phonet/socket.c
      	net/rds/af_rds.c
      	net/rfkill/core.c
      	net/sunrpc/cache.c
      	net/sunrpc/rpc_pipe.c
      	net/tipc/socket.c
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a57de0b4
  7. 03 6月, 2009 1 次提交
  8. 02 3月, 2009 2 次提交
    • G
      dccp: Do not let initial option overhead shrink the MPS · 86739fb9
      Gerrit Renker 提交于
      This fixes a problem caused by the overlap of the connection-setup and
      established-state phases of DCCP connections.
      
      During connection setup, the client retransmits Confirm Feature-Negotiation
      options until a response from the server signals that it can move from the
      half-established PARTOPEN into the OPEN state, whereupon the connection is
      fully established on both ends (RFC 4340, 8.1.5).
      
      However, since the client may already send data while it is in the PARTOPEN
      state, consequences arise for the Maximum Packet Size: the problem is that the
      initial option overhead is much higher than for the subsequent established
      phase, as it involves potentially many variable-length list-type options
      (server-priority options, RFC 4340, 6.4).
      
      Applying the standard MPS is insufficient here: especially with larger
      payloads this can lead to annoying, counter-intuitive EMSGSIZE errors.
      
      On the other hand, reducing the MPS available for the established phase by
      the added initial overhead is highly wasteful and inefficient.
      
      The solution chosen therefore is a two-phase strategy:
      
         If the payload length of the DataAck in PARTOPEN is too large, an Ack is sent
         to carry the options, and the feature-negotiation list is then flushed.
      
         This means that the server gets two Acks for one Response. If both Acks get
         lost, it is probably better to restart the connection anyway and devising yet
         another special-case does not seem worth the extra complexity.
      
      The result is a higher utilisation of the available packet space for the data
      transmission phase (established state) of a connection.
      
      The patch (over-)estimates the initial overhead to be 32*4 bytes -- commonly
      seen values were around 90 bytes for initial feature-negotiation options.
      
      It uses sizeof(u32) to mean "aligned units of 4 bytes".
      For consistency, another use of 4-byte alignment is adapted.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      86739fb9
    • G
      dccp: Minimise header option overhead in setting the MPS · 361a5c1d
      Gerrit Renker 提交于
      This patch resolves a long-standing FIXME to dynamically update the Maximum
      Packet Size depending on actual options usage.
      
      It uses the flags set by the feature-negotiation infrastructure to compute
      the required header option size.
      
      Most options are fixed-size, a notable exception are Ack Vectors (required
      currently only by CCID-2). These can have any length between 3 and 1020
      bytes. As a result of testing, 16 bytes (2 bytes for type/length plus 14 Ack
      Vector cells) have been found to be sufficient for loss-free situations.
      
      There are currently no CCID-specific header options which may appear on data
      packets, thus it is not necessary to define a corresponding CCID field as
      suggested in the old comment.
      
      Further changes:
      ----------------
       Adjusted the type of 'cur_mps' to match the unsigned return type of the
       function.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      361a5c1d
  9. 06 12月, 2008 1 次提交
  10. 17 11月, 2008 1 次提交
  11. 12 11月, 2008 1 次提交
    • G
      dccp: Resolve dependencies of features on choice of CCID · 9eca0a47
      Gerrit Renker 提交于
      This provides a missing link in the code chain, as several features implicitly
      depend and/or rely on the choice of CCID. Most notably, this is the Send Ack Vector
      feature, but also Ack Ratio and Send Loss Event Rate (also taken care of).
      
      For Send Ack Vector, the situation is as follows:
       * since CCID2 mandates the use of Ack Vectors, there is no point in allowing 
         endpoints which use CCID2 to disable Ack Vector features such a connection;
      
       * a peer with a TX CCID of CCID2 will always expect Ack Vectors, and a peer
         with a RX CCID of CCID2 must always send Ack Vectors (RFC 4341, sec. 4);
      
       * for all other CCIDs, the use of (Send) Ack Vector is optional and thus
         negotiable. However, this implies that the code negotiating the use of Ack
         Vectors also supports it (i.e. is able to supply and to either parse or
         ignore received Ack Vectors). Since this is not the case (CCID-3 has no Ack
         Vector support), the use of Ack Vectors is here disabled, with a comment
         in the source code.
      
      An analogous consideration arises for the Send Loss Event Rate feature,
      since the CCID-3 implementation does not support the loss interval options
      of RFC 4342. To make such use explicit, corresponding feature-negotiation
      options are inserted which signal the use of the loss event rate option,
      as it is used by the CCID3 code.
      
      Lastly, the values of the Ack Ratio feature are matched to the choice of CCID.
      
      The patch implements this as a function which is called after the user has
      made all other registrations for changing default values of features.
      
      The table is variable-length, the reserved (and hence for feature-negotiation
      invalid, confirmed by considering section 19.4 of RFC 4340) feature number `0'
      is used to mark the end of the table.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9eca0a47
  12. 20 10月, 2008 1 次提交
  13. 09 9月, 2008 1 次提交
  14. 04 9月, 2008 11 次提交
    • T
      dccp: Policy-based packet dequeueing infrastructure · d6da3511
      Tomasz Grobelny 提交于
      This patch adds a generic infrastructure for policy-based dequeueing of 
      TX packets and provides two policies:
       * a simple FIFO policy (which is the default) and
       * a priority based policy (set via socket options).
      Both policies honour the tx_qlen sysctl for the maximum size of the write
      queue (can be overridden via socket options). 
      
      The priority policy uses skb->priority internally to assign an u32 priority
      identifier, using the same ranking as SO_PRIORITY. The skb->priority field
      is set to 0 when the packet leaves DCCP. The priority is supplied as ancillary
      data using cmsg(3), the patch also provides the requisite parsing routines.
      Signed-off-by: NTomasz Grobelny <tomasz@grobelny.oswiecenia.net>
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      d6da3511
    • G
      dccp: Combine the functionality of enqeueing and cloning · b25b0c60
      Gerrit Renker 提交于
      Realising the following call pattern,
       * first dccp_entail() is called to enqueue a new skb and
       * then skb_clone() is called to transmit a clone of that skb,
      
      this patch integrates both interrelated steps into dccp_entail().
      
      Note: the return value of skb_clone is not checked. It may be an idea to add a
            warning if this occurs. In both instances, however, a timer is set for
            retransmission, so that cloning is re-tried via dccp_retransmit_skb().
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      b25b0c60
    • G
      dccp: Refine the wait-for-ccid mechanism · 146993cf
      Gerrit Renker 提交于
      This extends the existing wait-for-ccid routine so that it may be used with
      different types of CCID. It further addresses the problems listed below.
      
      The code looks if the write queue is non-empty and grants the TX CCID up to
      `timeout' jiffies to drain the queue. It will instead purge that queue if
       * the delay suggested by the CCID exceeds the time budget;
       * a socket error occurred while waiting for the CCID;
       * there is a signal pending (eg. annoyed user pressed Control-C);
       * the CCID does not support delays (we don't know how long it will take).
      
      
                       D e t a i l s  [can be removed]
                       -------------------------------
      DCCP's sending mechanism functions a bit like non-blocking I/O: dccp_sendmsg()
      will enqueue up to net.dccp.default.tx_qlen packets (default=5), without waiting
      for them to be released to the network.
      
      Rate-based CCIDs, such as CCID3/4, can impose sending delays of up to maximally
      64 seconds (t_mbi in RFC 3448). Hence the write queue may still contain packets
      when the application closes. Since the write queue is congestion-controlled by
      the CCID, draining the queue is also under control of the CCID.
      
      There are several problems that needed to be addressed:
       1) The queue-drain mechanism only works with rate-based CCIDs. If CCID2 for
          example has a full TX queue and becomes network-limited just as the
          application wants to close, then waiting for CCID2 to become unblocked could
          lead to an indefinite  delay (i.e., application "hangs").
       2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
          in its sending policy while the queue is being drained. This can lead to
          further delays during which the application will not be able to terminate.
       3) The minimum wait time for CCID3/4 can be expected to be the queue length
          times the current inter-packet delay. For example if tx_qlen=100 and a delay
          of 15 ms is used for each packet, then the application would have to wait
          for a minimum of 1.5 seconds before being allowed to exit.
       4) There is no way for the user/application to control this behaviour. It would
          be good to use the timeout argument of dccp_close() as an upper bound. Then
          the maximum time that an application is willing to wait for its CCIDs to can
          be set via the SO_LINGER option.
      
      These problems are addressed by giving the CCID a grace period of up to the
      `timeout' value.
      
      The wait-for-ccid function is, as before, used when the application 
       (a) has read all the data in its receive buffer and
       (b) if SO_LINGER was set with a non-zero linger time, or
       (c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
           state (client application closes after receiving CloseReq).
      
      In addition, there is a catch-all case by calling __skb_queue_purge() after 
      waiting for the CCID. This is necessary since the write queue may still have
      data when
       (a) the host has been passively-closed,
       (b) abnormal termination (unread data, zero linger time),
       (c) wait-for-ccid could not finish within the given time limit.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      146993cf
    • G
      dccp: Extend CCID packet dequeueing interface · e7937772
      Gerrit Renker 提交于
      This extends the packet dequeuing interface of dccp_write_xmit() to allow
       1. CCIDs to take care of timing when the next packet may be sent;
       2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
      
      The main purpose is to take CCID2 out of its polling mode (when it is network-
      limited, it tries every millisecond to send, without interruption).
      The interface can also be used to support other CCIDs.
      
      The mode of operation for (2) is as follows:
       * new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
       * ccid_hc_tx_send_packet() detects that it may not send (e.g. window full), 
       * it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
       * dccp_write_xmit() returns without further action;
       * after some time the wait-condition for CCID becomes true,
       * that CCID schedules the tasklet,
       * tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
       * since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
       * packet is sent, and possibly more (since dccp_write_xmit() loops).
      
      Code reuse: the taskled function calls dccp_write_xmit(), the timer function
                  reduces to a wrapper around the same code.
      
      If the tasklet finds that the socket is locked, it re-schedules the tasklet
      function (not the tasklet) after one jiffy.
      
      Changed DCCP_BUG to dccp_pr_debug when transmit_skb returns an error (e.g. when a
      local qdisc is used, NET_XMIT_DROP=1 can be returned for many packets).
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      e7937772
    • G
      dccp ccid-2: Schedule Sync as out-of-band mechanism · c2f42077
      Gerrit Renker 提交于
      The problem with Ack Vectors is that 
      
        i) their length is variable and can in principle grow quite large,
       ii) it is hard to predict exactly how large they will be.
      
      Due to the second point it seems not a good idea to reduce the MPS; in
      particular when on average there is enough room for the Ack Vector and an
      increase in length is momentarily due to some burst loss, after which the
      Ack Vector returns to its normal/average length.
      
      The solution taken by this patch is to subtract a minimum-expected Ack Vector
      length from the MPS (previous patch), and to defer any larger Ack Vectors onto
      a separate Sync - but only if indeed there is no space left on the skb.
      
      This patch provides the infrastructure to schedule Sync-packets for transporting
      (urgent) out-of-band data. Its signalling is quicker than scheduling an Ack, since
      it does not need to wait for new application data.
      
      It can thus serve other parts of the DCCP code as well.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      c2f42077
    • G
      dccp: Merge now-reduced connect_init() function · a9c1656a
      Gerrit Renker 提交于
      After moving the assignment of GAR/ISS from dccp_connect_init() to
      dccp_transmit_skb(), the former function becomes very small, so that
      a merger with dccp_connect() suggests itself.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      a9c1656a
    • G
      dccp: Unused argument in CCID tx function · c506d91d
      Gerrit Renker 提交于
      This removes the argument `more' from ccid_hc_tx_packet_sent, since it was
      nowhere used in the entire code.
      
      (Anecdotally, this argument was not even used in the original KAME code where
       the function originally came from; compare the variable moreToSend in the
       freebsd61-dccp-kame-28.08.2006.patch now maintained by Emmanuel Lochin.)
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      c506d91d
    • G
      dccp: Special case of the MPS for client-PARTOPEN with DataAcks · 88ddac51
      Gerrit Renker 提交于
      To increase robustness, it is necessary to resend Confirm feature-negotiation
      options, even though the RFC does not mandate it. But feature negotiation
      options can take (much) more room than the options on common DataAck packets.
      
      Instead of reducing the MPS always for a case which only applies to the three
      messages send during initial handshake, this patch devises a special case:
      
         if the payload length of the DataAck in PARTOPEN is too large, an Ack is sent
         to carry the options, and the feature-negotiation list is then flushed.
      
         This means that the server gets two Acks for one Response. If both Acks get
         lost, it is probably better to restart the connection anyway and devising yet
         another special-case does not seem worth the extra complexity.
      
      The patch (over-)estimates the expected overhead to be 32*4 bytes -- commonly
      seen values were 20-90 bytes for initial feature-negotiation options. 
      
      It uses sizeof(u32) to mean "aligned units of 4 bytes". For consistency,
      another use of sizeof is modified.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      88ddac51
    • G
      dccp: Leave headroom for options when calculating the MPS · 55ebe3ab
      Gerrit Renker 提交于
      The Maximum Packet Size (MPS) is of interest for applications which want
      to transfer data, so it is only relevant to the data transfer phase of a
      connection (unless one wants to send data on the DCCP-Request, but that is
      not considered here).
      
      The strategy chosen to deal with this requirement is to leave room for only 
      such options that may appear on data packets.
      
      A special consideration applies to Ack Vectors: this is purely guesswork,
      since these can have any length between 3 and 1020 bytes. The strategy
      chosen here is to subtract a configurable minimum, the value of 16 bytes
      (2 bytes for type/length plus 14 Ack Vector cells) has been found by 
      experimentatation. If people experience this as too much or too little,
      this could later be turned into a Kconfig option.	
      
      There are currently no CCID-specific header options which may appear on data
      packets, hence it is not necessary to define a corresponding CCID field.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      55ebe3ab
    • G
      dccp: Mechanism to resolve CCID dependencies · d4c8741c
      Gerrit Renker 提交于
      This adds a hook to resolve features whose value depends on the choice of
      CCID. It is done at the server since it can only be done after the CCID
      values have been negotiated; i.e. the client will add its CCID preference
      list on the Change options sent in the Request, which will be reconciled
      with the local preference list of the server.
      
      The concept is documented on 
      http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/feature_negotiation/\
      				implementation_notes.html#ccid_dependencies
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      d4c8741c
    • G
      dccp: Resolve dependencies of features on choice of CCID · 093e1f46
      Gerrit Renker 提交于
      This provides a missing link in the code chain, as several features implicitly
      depend and/or rely on the choice of CCID. Most notably, this is the Send Ack Vector
      feature, but also Ack Ratio and Send Loss Event Rate (also taken care of).
      
      For Send Ack Vector, the situation is as follows:
       * since CCID2 mandates the use of Ack Vectors, there is no point in allowing 
         endpoints which use CCID2 to disable Ack Vector features such a connection;
      
       * a peer with a TX CCID of CCID2 will always expect Ack Vectors, and a peer
         with a RX CCID of CCID2 must always send Ack Vectors (RFC 4341, sec. 4);
      
       * for all other CCIDs, the use of (Send) Ack Vector is optional and thus
         negotiable. However, this implies that the code negotiating the use of Ack
         Vectors also supports it (i.e. is able to supply and to either parse or
         ignore received Ack Vectors). Since this is not the case (CCID-3 has no Ack
         Vector support), the use of Ack Vectors is here disabled, with a comment
         in the source code.
      
      An analogous consideration arises for the Send Loss Event Rate feature,
      since the CCID-3 implementation does not support the loss interval options
      of RFC 4342. To make such use explicit, corresponding feature-negotiation
      options are inserted which signal the use of the loss event rate option,
      as it is used by the CCID3 code.
      
      Lastly, the values of the Ack Ratio feature are matched to the choice of CCID.
      
      The patch implements this as a function which is called after the user has
      made all other registrations for changing default values of features.
      
      The table is variable-length, the reserved (and hence for feature-negotiation
      invalid, confirmed by considering section 19.4 of RFC 4340) feature number `0'
      is used to mark the end of the table.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      093e1f46
  15. 26 7月, 2008 2 次提交
    • G
      dccp: Bug-Fix - AWL was never updated · 73f18fdb
      Gerrit Renker 提交于
      The AWL lower Ack validity window advances in proportion to GSS, the greatest
      sequence number sent. Updating AWL other than at connection setup (in the
      DCCP-Request sent by dccp_v{4,6}_connect()) was missing in the DCCP code.
      
      This bug lead to syslog messages such as
      
       "kernel: dccp_check_seqno: DCCP: Step 6 failed for DATAACK packet, [...] 
        P.ackno exists or LAWL(82947089) <= P.ackno(82948208)
                                         <= S.AWH(82948728), sending SYNC..."
      
      The difference between AWL/AWH here is 1639 packets, while the expected value
      (the Sequence Window) would have been 100 (the default).  A closer look showed
      that LAWL = AWL = 82947089 equalled the ISS on the Response.
      
      The patch now updates AWL with each increase of GSS.
      
      
      Further changes:
      ----------------
      The patch also enforces more stringent checks on the ISS sequence number:
      
       * AWL is initialised to ISS at connection setup and remains at this value;
       * AWH is then always set to GSS (via dccp_update_gss());
       * so on the first Request: AWL =      AWH = ISS,
         and on the n-th Request: AWL = ISS, AWH = ISS + n.
      
      As a consequence, only Response packets that refer to Requests sent by this
      host will pass, all others are discarded. This is the intention and in effect 
      implements the initial adjustments for AWL as specified in RFC 4340, 7.5.1.
      
      Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>   
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      73f18fdb
    • G
      dccp: Allow to distinguish original and retransmitted packets · 59435444
      Gerrit Renker 提交于
      This patch allows the sender to distinguish original and retransmitted packets,
      which is in particular needed for the retransmission of DCCP-Requests:
       * the first Request uses ISS (generated in net/dccp/ip*.c), and sets GSS = ISS;
       * all retransmitted Requests use GSS' = GSS + 1, so that the n-th retransmitted
         Request has sequence number ISS + n (mod 48).
      
      To add generic support, the patch reorganises existing code so that:
       * icsk_retransmits == 0     for the original packet and
       * icsk_retransmits = n > 0  for the n-th retransmitted packet
      at the time dccp_transmit_skb() is called, via dccp_retransmit_skb().
       
      Thanks to Wei Yongjun for pointing this problem out.
      
      Further changes:
      ----------------
       * removed the `skb' argument from dccp_retransmit_skb(), since sk_send_head
         is used for all retransmissions (the exception is client-Acks in PARTOPEN
         state, but these do not use sk_send_head);
       * since sk_send_head always contains the original skb (via dccp_entail()),
         skb_cloned() never evaluated to true and thus pskb_copy() was never used.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      59435444
  16. 11 6月, 2008 1 次提交
    • G
      dccp: Fix sparse warnings · 1e2f0e5e
      Gerrit Renker 提交于
      This patch fixes the following sparse warnings:
       * nested min(max()) expression:
         net/dccp/ccids/ccid3.c:91:21: warning: symbol '__x' shadows an earlier one
         net/dccp/ccids/ccid3.c:91:21: warning: symbol '__y' shadows an earlier one
         
       * Declaration of function prototypes in .c instead of .h file, resulting in
         "should it be static?" warnings. 
      
       * Declared "struct dccpw" static (local to dccp_probe).
       
       * Disabled dccp_delayed_ack() - not fully removed due to RFC 4340, 11.3
         ("Receivers SHOULD implement delayed acknowledgement timers ...").
      
       * Used a different local variable name to avoid
         net/dccp/ackvec.c:293:13: warning: symbol 'state' shadows an earlier one
         net/dccp/ackvec.c:238:33: originally declared here
      
       * Removed unused functions `dccp_ackvector_print' and `dccp_ackvec_print'.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      1e2f0e5e
  17. 13 4月, 2008 1 次提交
    • P
      [DCCP]: Fix skb->cb conflicts with IP · 028b0275
      Patrick McHardy 提交于
      dev_queue_xmit() and the other IP output functions expect to get a skb
      with clear or properly initialized skb->cb. Unlike TCP and UDP, the
      dccp_skb_cb doesn't contain a struct inet_skb_parm at the beginning,
      so the DCCP-specific data is interpreted by the IP output functions.
      This can cause false negatives for the conditional POST_ROUTING hook
      invocation, making the packet bypass the hook.
      
      Add a inet_skb_parm/inet6_skb_parm union to the beginning of
      dccp_skb_cb to avoid clashes. Also add a BUILD_BUG_ON to make
      sure it fits in the cb.
      
      [ Combined with patch from Gerrit Renker to remove two now unnecessary
        memsets of IPCB(skb)->opt ]
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      028b0275
  18. 04 4月, 2008 1 次提交
  19. 29 1月, 2008 6 次提交
  20. 11 10月, 2007 4 次提交
    • G
      [DCCP]: Wait for CCID · bc849872
      Gerrit Renker 提交于
      This performs a minor optimisation: when ccid_hc_tx_send_packet
      returns a value greater zero, then the same call previously was done
      again at the begin of the while loop in dccp_wait_for_ccid.
      
      This patch exploits the available information and schedule-timeouts
      directly instead.
      
      Documentation also added.
      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>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc849872
    • G
      [DCCP]: Factor out common code for generating Resets · e356d37a
      Gerrit Renker 提交于
      This factors code common to dccp_v{4,6}_ctl_send_reset into a separate function,
      and adds support for filling in the Data 1 ... Data 3 fields from RFC 4340, 5.6.
      
      It is useful to have this separate, since the following Reset codes will always
      be generated from the control socket rather than via dccp_send_reset:
       * Code 3, "No Connection", cf. 8.3.1;
       * Code 4, "Packet Error" (identification for Data 1 added);
       * Code 5, "Option Error" (identification for Data 1..3 added, will be used later);
       * Code 6, "Mandatory Error" (same as Option Error);
       * Code 7, "Connection Refused" (what on Earth is the difference to "No Connection"?);
       * Code 8, "Bad Service Code";
       * Code 9, "Too Busy";
       * Code 10, "Bad Init Cookie" (not used).
      
      Code 0 is not recommended by the RFC, the following codes would be used in
      dccp_send_reset() instead, since they all relate to an established DCCP connection:
       * Code 1, "Closed";
       * Code 2, "Aborted";
       * Code 11, "Aggression Penalty" (12.3).
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      e356d37a
    • G
      [DCCP]: Remove duplicate code for Reset from connected socket · ee1a1592
      Gerrit Renker 提交于
      In this patch, duplicated code is removed for the case when a Reset packet is
      sent from a connected socket. This code duplication is between dccp_make_reset
      and dccp_transmit_skb, which already contained an (up to now entirely unused)
      switch statement to fill in the reset code from the DCCP_SKB_CB.
      
      The only thing that has been removed is the call to dst_clone(dst), since
      the queue_xmit functions use sk_dst_cache anyway.
      
      I wasn't sure which purpose inet_sk_rebuild_header served, so I left it in.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      ee1a1592
    • G
      [DCCP]: Add FIXME for send_delayed_ack · 727ecc5f
      Gerrit Renker 提交于
      This adds a FIXME to signal that the function dccp_send_delayed_ack is nowhere
      used in the entire DCCP/CCID code.
      
      Using a delayed Ack timer is suggested in 11.3 of RFC 4340, but it has also
      rather subtle implications for the Ack-Ratio-accounting.
      
      CCID2 does not use this (maybe it should).
      
      I think leaving the function in is good, in case someone wants to implement
      this.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      727ecc5f