1. 19 Mar, 2013 1 commit
  2. 15 Mar, 2013 3 commits
  3. 14 Mar, 2013 1 commit
  4. 13 Mar, 2013 2 commits
  5. 12 Mar, 2013 3 commits
  6. 11 Mar, 2013 1 commit
  7. 10 Mar, 2013 4 commits
  8. 08 Mar, 2013 5 commits
  9. 07 Mar, 2013 4 commits
  10. 06 Mar, 2013 13 commits
    • David Ward's avatar
      net/ipv4: Timestamp option cannot overflow with prespecified addresses · fa2b04f4
      David Ward authored
      
      
      When a router forwards a packet that contains the IPv4 timestamp option,
      if there is no space left in the option for the router to add its own
      timestamp, then the router increments the Overflow value in the option.
      
      However, if the addresses of the routers are prespecified in the option,
      then the overflow condition cannot happen: the option is structured so
      that each prespecified router has a place to write its timestamp. Other
      routers do not add a timestamp, so there will never be a lack of space.
      
      This fix ensures that the Overflow value in the IPv4 timestamp option is
      not incremented when the addresses of the routers are prespecified, even
      if the Pointer value is greater than the Length value.
      Signed-off-by: default avatarDavid Ward <david.ward@ll.mit.edu>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa2b04f4
    • Eric Dumazet's avatar
      net: reduce net_rx_action() latency to 2 HZ · d1f41b67
      Eric Dumazet authored
      We should use time_after_eq() to get maximum latency of two ticks,
      instead of three.
      
      Bug added in commit 24f8b238
      
       (net: increase receive packet quantum)
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d1f41b67
    • Randy Dunlap's avatar
      net: fix new kernel-doc warnings in net core · 691b3b7e
      Randy Dunlap authored
      
      
      Fix new kernel-doc warnings in net/core/dev.c:
      
      Warning(net/core/dev.c:4788): No description found for parameter 'new_carrier'
      Warning(net/core/dev.c:4788): Excess function parameter 'new_carries' description in 'dev_change_carrier'
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      691b3b7e
    • Paolo Valente's avatar
      pkt_sched: sch_qfq: remove a useless invocation of qfq_update_eligible · 76e4cb0d
      Paolo Valente authored
      
      
      QFQ+ can select for service only 'eligible' aggregates, i.e.,
      aggregates that would have started to be served also in the emulated
      ideal system.  As a consequence, for QFQ+ to be work conserving, at
      least one of the active aggregates must be eligible when it is time to
      choose the next aggregate to serve.
      
      The set of eligible aggregates is updated through the function
      qfq_update_eligible(), which does guarantee that, after its
      invocation, at least one of the active aggregates is eligible.
      Because of this property, this function is invoked in
      qfq_deactivate_agg() to guarantee that at least one of the active
      aggregates is still eligible after an aggregate has been deactivated.
      In particular, the critical case is when there are other active
      aggregates, but the aggregate being deactivated happens to be the only
      one eligible.
      
      However, this precaution is not needed for QFQ+ to be work conserving,
      because update_eligible() is always invoked also at the beginning of
      qfq_choose_next_agg(). This patch removes the additional invocation of
      update_eligible() in qfq_deactivate_agg().
      Signed-off-by: default avatarPaolo Valente <paolo.valente@unimore.it>
      Reviewed-by: default avatarFabio Checconi <fchecconi@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      76e4cb0d
    • Paolo Valente's avatar
      pkt_sched: sch_qfq: do not allow virtual time to jump if an aggregate is in service · 40dd2d54
      Paolo Valente authored
      
      
      By definition of (the algorithm of) QFQ+, the system virtual time must
      be pushed up only if there is no 'eligible' aggregate, i.e. no
      aggregate that would have started to be served also in the ideal
      system emulated by QFQ+.  QFQ+ serves only eligible aggregates, hence
      the aggregate currently in service is eligible.  As a consequence, to
      decide whether there is no eligible aggregate, QFQ+ must also check
      whether there is no aggregate in service.
      Signed-off-by: default avatarPaolo Valente <paolo.valente@unimore.it>
      Reviewed-by: default avatarFabio Checconi <fchecconi@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      40dd2d54
    • Paolo Valente's avatar
      pkt_sched: sch_qfq: prevent budget from wrapping around after a dequeue · a0143efa
      Paolo Valente authored
      
      
      Aggregate budgets are computed so as to guarantee that, after an
      aggregate has been selected for service, that aggregate has enough
      budget to serve at least one maximum-size packet for the classes it
      contains. For this reason, after a new aggregate has been selected
      for service, its next packet is immediately dequeued, without any
      further control.
      
      The maximum packet size for a class, lmax, can be changed through
      qfq_change_class(). In case the user sets lmax to a lower value than
      the the size of some of the still-to-arrive packets, QFQ+ will
      automatically push up lmax as it enqueues these packets.  This
      automatic push up is likely to happen with TSO/GSO.
      
      In any case, if lmax is assigned a lower value than the size of some
      of the packets already enqueued for the class, then the following
      problem may occur: the size of the next packet to dequeue for the
      class may happen to be larger than lmax, after the aggregate to which
      the class belongs has been just selected for service. In this case,
      even the budget of the aggregate, which is an unsigned value, may be
      lower than the size of the next packet to dequeue. After dequeueing
      this packet and subtracting its size from the budget, the latter would
      wrap around.
      
      This fix prevents the budget from wrapping around after any packet
      dequeue.
      Signed-off-by: default avatarPaolo Valente <paolo.valente@unimore.it>
      Reviewed-by: default avatarFabio Checconi <fchecconi@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0143efa
    • Paolo Valente's avatar
      pkt_sched: sch_qfq: serve activated aggregates immediately if the scheduler is empty · 2f3b89a1
      Paolo Valente authored
      
      
      If no aggregate is in service, then the function qfq_dequeue() does
      not dequeue any packet. For this reason, to guarantee QFQ+ to be work
      conserving, a just-activated aggregate must be set as in service
      immediately if it happens to be the only active aggregate.
      This is done by the function qfq_enqueue().
      
      Unfortunately, the function qfq_add_to_agg(), used to add a class to
      an aggregate, does not perform this important additional operation.
      In particular, if: 1) qfq_add_to_agg() is invoked to complete the move
      of a class from a source aggregate, becoming, for this move, inactive,
      to a destination aggregate, becoming instead active, and 2) the
      destination aggregate becomes the only active aggregate, then this
      aggregate is not however set as in service. QFQ+ remains then in a
      non-work-conserving state until a new invocation of qfq_enqueue()
      recovers the situation.
      
      This fix solves the problem by moving the logic for setting an
      aggregate as in service directly into the function qfq_activate_agg().
      Hence, from whatever point qfq_activate_aggregate() is invoked, QFQ+
      remains work conserving.  Since the more-complex logic of this new
      version of activate_aggregate() is not necessary, in qfq_dequeue(), to
      reschedule an aggregate that finishes its budget, then the aggregate
      is now rescheduled by invoking directly the functions needed.
      Signed-off-by: default avatarPaolo Valente <paolo.valente@unimore.it>
      Reviewed-by: default avatarFabio Checconi <fchecconi@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2f3b89a1
    • Paolo Valente's avatar
      pkt_sched: sch_qfq: fix the update of eligible-group sets · 624b85fb
      Paolo Valente authored
      
      
      Between two invocations of make_eligible, the system virtual time may
      happen to grow enough that, in its binary representation, a bit with
      higher order than 31 flips. This happens especially with
      TSO/GSO. Before this fix, the mask used in make_eligible was computed
      as (1UL<<index_of_last_flipped_bit)-1, whose value is well defined on
      a 64-bit architecture, because index_of_flipped_bit <= 63, but is in
      general undefined on a 32-bit architecture if index_of_flipped_bit > 31.
      The fix just replaces 1UL with 1ULL.
      Signed-off-by: default avatarPaolo Valente <paolo.valente@unimore.it>
      Reviewed-by: default avatarFabio Checconi <fchecconi@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      624b85fb
    • Paolo Valente's avatar
      pkt_sched: sch_qfq: properly cap timestamps in charge_actual_service · 9b99b7e9
      Paolo Valente authored
      
      
      QFQ+ schedules the active aggregates in a group using a bucket list
      (one list per group). The bucket in which each aggregate is inserted
      depends on the aggregate's timestamps, and the number
      of buckets in a group is enough to accomodate the possible (range of)
      values of the timestamps of all the aggregates in the group. For this
      property to hold, timestamps must however be computed correctly.  One
      necessary condition for computing timestamps correctly is that the
      number of bits dequeued for each aggregate, while the aggregate is in
      service, does not exceed the maximum budget budgetmax assigned to the
      aggregate.
      
      For each aggregate, budgetmax is proportional to the number of classes
      in the aggregate. If the number of classes of the aggregate is
      decreased through qfq_change_class(), then budgetmax is decreased
      automatically as well.  Problems may occur if the aggregate is in
      service when budgetmax is decreased, because the current remaining
      budget of the aggregate and/or the service already received by the
      aggregate may happen to be larger than the new value of budgetmax.  In
      this case, when the aggregate is eventually deselected and its
      timestamps are updated, the aggregate may happen to have received an
      amount of service larger than budgetmax.  This may cause the aggregate
      to be assigned a higher virtual finish time than the maximum
      acceptable value for the last bucket in the bucket list of the group.
      
      This fix introduces a cap that addresses this issue.
      Signed-off-by: default avatarPaolo Valente <paolo.valente@unimore.it>
      Reviewed-by: default avatarFabio Checconi <fchecconi@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b99b7e9
    • Peter Hurley's avatar
      net/irda: Raise dtr in non-blocking open · f74861ca
      Peter Hurley authored
      
      
      DTR/RTS need to be raised, regardless of the open() mode, but not
      if the port has already shutdown.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f74861ca
    • Peter Hurley's avatar
      net/irda: Use barrier to set task state · 0b176ce3
      Peter Hurley authored
      
      
      Without a memory and compiler barrier, the task state change
      can migrate relative to the condition testing in a blocking loop.
      However, the task state change must be visible across all cpus
      prior to testing those conditions. Failing to do this can result
      in the familiar 'lost wakeup' and this task will hang until killed.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b176ce3
    • Peter Hurley's avatar
      net/irda: Hold port lock while bumping blocked_open · 2f7c069b
      Peter Hurley authored
      
      
      Although tty_lock() already protects concurrent update to
      blocked_open, that fails to meet the separation-of-concerns between
      tty_port and tty.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2f7c069b
    • Peter Hurley's avatar
      net/irda: Fix port open counts · a4ed2e73
      Peter Hurley authored
      
      
      Saving the port count bump is unsafe. If the tty is hung up while
      this open was blocking, the port count is zeroed.
      
      Explicitly check if the tty was hung up while blocking, and correct
      the port count if not.
      Signed-off-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4ed2e73
  11. 04 Mar, 2013 3 commits