1. 13 4月, 2008 2 次提交
  2. 08 4月, 2008 1 次提交
    • I
      [TCP]: tcp_simple_retransmit can cause S+L · 882bebaa
      Ilpo Järvinen 提交于
      This fixes Bugzilla #10384
      
      tcp_simple_retransmit does L increment without any checking
      whatsoever for overflowing S+L when Reno is in use.
      
      The simplest scenario I can currently think of is rather
      complex in practice (there might be some more straightforward
      cases though). Ie., if mss is reduced during mtu probing, it
      may end up marking everything lost and if some duplicate ACKs
      arrived prior to that sacked_out will be non-zero as well,
      leading to S+L > packets_out, tcp_clean_rtx_queue on the next
      cumulative ACK or tcp_fastretrans_alert on the next duplicate
      ACK will fix the S counter.
      
      More straightforward (but questionable) solution would be to
      just call tcp_reset_reno_sack() in tcp_simple_retransmit but
      it would negatively impact the probe's retransmission, ie.,
      the retransmissions would not occur if some duplicate ACKs
      had arrived.
      
      So I had to add reno sacked_out reseting to CA_Loss state
      when the first cumulative ACK arrives (this stale sacked_out
      might actually be the explanation for the reports of left_out
      overflows in kernel prior to 2.6.23 and S+L overflow reports
      of 2.6.24). However, this alone won't be enough to fix kernel
      before 2.6.24 because it is building on top of the commit
      1b6d427b ([TCP]: Reduce sacked_out with reno when purging
      write_queue) to keep the sacked_out from overflowing.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Reported-by: NAlessandro Suardi <alessandro.suardi@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      882bebaa
  3. 03 4月, 2008 3 次提交
  4. 02 4月, 2008 1 次提交
  5. 01 4月, 2008 3 次提交
  6. 31 3月, 2008 4 次提交
  7. 30 3月, 2008 2 次提交
  8. 29 3月, 2008 5 次提交
  9. 28 3月, 2008 4 次提交
  10. 27 3月, 2008 4 次提交
    • F
      rdc321x: GPIO routines bugfixes · b2ef7497
      Florian Fainelli 提交于
      This patch fixes the use of GPIO routines which are in the PCI
      configuration space of the RDC321x, therefore reading/writing
      to this space without spinlock protection can be problematic.
      
      We also now request and free GPIOs and support the MGB100
      board, previous code was very AR525W-centric.
      Signed-off-by: NVolker Weiss <volker@tintuc.de>
      Signed-off-by: NFlorian Fainelli <florian.fainelli@telecomint.eu>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b2ef7497
    • D
      [SPARC64]: Define TASK_SIZE_OF() · c101b088
      David S. Miller 提交于
      This make "cat /proc/${PID}/pagemap" more efficient for
      32-bit tasks.
      
      Based upon a report by Mariusz Kozlowski.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c101b088
    • H
      [IPSEC]: Fix BEET output · 732c8bd5
      Herbert Xu 提交于
      The IPv6 BEET output function is incorrectly including the inner
      header in the payload to be protected.  This causes a crash as
      the packet doesn't actually have that many bytes for a second
      header.
      
      The IPv4 BEET output on the other hand is broken when it comes
      to handling an inner IPv6 header since it always assumes an
      inner IPv4 header.
      
      This patch fixes both by making sure that neither BEET output
      function touches the inner header at all.  All access is now
      done through the protocol-independent cb structure.  Two new
      attributes are added to make this work, the IP header length
      and the IPv4 option length.  They're filled in by the inner
      mode's output function.
      
      Thanks to Joakim Koskela for finding this problem.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      732c8bd5
    • S
      x86: fix performance drop for glx · d546b67a
      Suresh Siddha 提交于
      fix the 3D performance drop reported at:
      
         http://bugzilla.kernel.org/show_bug.cgi?id=10328
      
      fb drivers are using ioremap()/ioremap_nocache(), followed by mtrr_add with
      WC attribute. Recent changes in page attribute code made both
      ioremap()/ioremap_nocache() mappings as UC (instead of previous UC-). This
      breaks the graphics performance, as the effective memory type is UC instead
      of expected WC.
      
      The correct way to fix this is to add ioremap_wc() (which uses UC- in the
      absence of PAT kernel support and WC with PAT) and change all the
      fb drivers to use this new ioremap_wc() API.
      
      We can take this correct and longer route for post 2.6.25. For now,
      revert back to the UC- behavior for ioremap/ioremap_nocache.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d546b67a
  11. 26 3月, 2008 9 次提交
  12. 25 3月, 2008 2 次提交