1. 04 10月, 2005 1 次提交
    • H
      [NET]: Fix packet timestamping. · 325ed823
      Herbert Xu 提交于
      I've found the problem in general.  It affects any 64-bit
      architecture.  The problem occurs when you change the system time.
      
      Suppose that when you boot your system clock is forward by a day.
      This gets recorded down in skb_tv_base.  You then wind the clock back
      by a day.  From that point onwards the offset will be negative which
      essentially overflows the 32-bit variables they're stored in.
      
      In fact, why don't we just store the real time stamp in those 32-bit
      variables? After all, we're not going to overflow for quite a while
      yet.
      
      When we do overflow, we'll need a better solution of course.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      325ed823
  2. 27 9月, 2005 1 次提交
  3. 21 9月, 2005 1 次提交
    • E
      [AF_PACKET]: Allow for > 8 byte hardware addresses. · 0fb375fb
      Eric W. Biederman 提交于
      The convention is that longer addresses will simply extend
      the hardeware address byte arrays at the end of sockaddr_ll and
      packet_mreq.
      
      In making this change a small information leak was also closed.
      The code only initializes the hardware address bytes that are
      used, but all of struct sockaddr_ll was copied to userspace.
      Now we just copy sockaddr_ll to the last byte of the hardware
      address used.
      
      For error checking larger structures than our internal
      maximums continue to be allowed but an error is signaled if we can
      not fit the hardware address into our internal structure.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0fb375fb
  4. 07 9月, 2005 1 次提交
  5. 30 8月, 2005 2 次提交
  6. 13 7月, 2005 1 次提交
  7. 06 5月, 2005 1 次提交
  8. 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