1. 14 3月, 2016 1 次提交
    • A
      ipv4: Update parameters for csum_tcpudp_magic to their original types · 01cfbad7
      Alexander Duyck 提交于
      This patch updates all instances of csum_tcpudp_magic and
      csum_tcpudp_nofold to reflect the types that are usually used as the source
      inputs.  For example the protocol field is populated based on nexthdr which
      is actually an unsigned 8 bit value.  The length is usually populated based
      on skb->len which is an unsigned integer.
      
      This addresses an issue in which the IPv6 function csum_ipv6_magic was
      generating a checksum using the full 32b of skb->len while
      csum_tcpudp_magic was only using the lower 16 bits.  As a result we could
      run into issues when attempting to adjust the checksum as there was no
      protocol agnostic way to update it.
      
      With this change the value is still truncated as many architectures use
      "(len + proto) << 8", however this truncation only occurs for values
      greater than 16776960 in length and as such is unlikely to occur as we stop
      the inner headers at ~64K in size.
      
      I did have to make a few minor changes in the arm, mn10300, nios2, and
      score versions of the function in order to support these changes as they
      were either using things such as an OR to combine the protocol and length,
      or were using ntohs to convert the length which would have truncated the
      value.
      
      I also updated a few spots in terms of whitespace and type differences for
      the addresses.  Most of this was just to make sure all of the definitions
      were in sync going forward.
      Signed-off-by: NAlexander Duyck <aduyck@mirantis.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      01cfbad7
  2. 29 12月, 2013 1 次提交
    • R
      ARM: fix csum_tcpudp_magic() miscompilation · d46cda12
      Russell King 提交于
      There is a miscompilation of csum_tcpudp_magic() due to the way we pass
      the asm() operands in.  Fortunately, this doesn't affect the IP code,
      but can affect anyone who passes ntohs(udp->len) as the length argument,
      or protocols with more than 8 bits.
      
      The problem stems from passing 16-bit operands into an asm() - GCC makes
      no guarantees about what may be in the high 16-bits of such a register
      passed into assembly which is in the "HI" machine mode.
      
      Address this by changing the way we handle the 16-bit arguments - since
      accumulating the protocol and length can never overflow, we can delegate
      this to the compiler to perform, and then accumulate it into the
      checksum inside the asm(), taking account of the endian-ness via an
      appropriate 32-bit rotation.
      
      While we are here, also realise that there's a chance to optimise this
      a little: several callers from IP code pass a constant zero as the
      initial sum.  This is wasteful - if we detect this condition, we can
      optimise away one instruction.
      Tested-by: NMaxime Bizon <mbizon@freebox.fr>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d46cda12
  3. 03 8月, 2008 1 次提交
  4. 07 2月, 2007 1 次提交
    • R
      [ARM] Improve csum_fold, cleanup csum_tcpudp_magic() · 7ef416c4
      Russell King 提交于
      csum_fold doesn't need two assembly instructions to perform its task,
      it can simply add the high and low parts together by rotating by 16
      bits, and the carry into the upper-16 bits will automatically happen.
      
      Also, since csum_tcpudp_magic() is just csum_tcpudp_nofold + csum_fold,
      use those two functions to achieve this.  Also note that there is a
      csum_fold() at the end of ip_fast_csum() as well, so use the real
      csum_fold() there as well.
      
      Boot tested on Versatile.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7ef416c4
  5. 03 12月, 2006 1 次提交
  6. 02 2月, 2006 1 次提交
  7. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4