1. 26 4月, 2007 4 次提交
    • A
      [SK_BUFF]: Introduce skb_reset_network_header(skb) · c1d2bbe1
      Arnaldo Carvalho de Melo 提交于
      For the common, open coded 'skb->nh.raw = skb->data' operation, so that we can
      later turn skb->nh.raw into a offset, reducing the size of struct sk_buff in
      64bit land while possibly keeping it as a pointer on 32bit.
      
      This one touches just the most simple case, next will handle the slightly more
      "complex" cases.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c1d2bbe1
    • A
      [SK_BUFF]: Introduce skb_mac_header() · 98e399f8
      Arnaldo Carvalho de Melo 提交于
      For the places where we need a pointer to the mac header, it is still legal to
      touch skb->mac.raw directly if just adding to, subtracting from or setting it
      to another layer header.
      
      This one also converts some more cases to skb_reset_mac_header() that my
      regex missed as it had no spaces before nor after '=', ugh.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      98e399f8
    • E
      [NET]: Introduce SIOCGSTAMPNS ioctl to get timestamps with nanosec resolution · ae40eb1e
      Eric Dumazet 提交于
      Now network timestamps use ktime_t infrastructure, we can add a new
      ioctl() SIOCGSTAMPNS command to get timestamps in 'struct timespec'.
      User programs can thus access to nanosecond resolution.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      CC: Stephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae40eb1e
    • E
      [NET]: convert network timestamps to ktime_t · b7aa0bf7
      Eric Dumazet 提交于
      We currently use a special structure (struct skb_timeval) and plain
      'struct timeval' to store packet timestamps in sk_buffs and struct
      sock.
      
      This has some drawbacks :
      - Fixed resolution of micro second.
      - Waste of space on 64bit platforms where sizeof(struct timeval)=16
      
      I suggest using ktime_t that is a nice abstraction of high resolution
      time services, currently capable of nanosecond resolution.
      
      As sizeof(ktime_t) is 8 bytes, using ktime_t in 'struct sock' permits
      a 8 byte shrink of this structure on 64bit architectures. Some other
      structures also benefit from this size reduction (struct ipq in
      ipv4/ip_fragment.c, struct frag_queue in ipv6/reassembly.c, ...)
      
      Once this ktime infrastructure adopted, we can more easily provide
      nanosecond resolution on top of it. (ioctl SIOCGSTAMPNS and/or
      SO_TIMESTAMPNS/SCM_TIMESTAMPNS)
      
      Note : this patch includes a bug correction in
      compat_sock_get_timestamp() where a "err = 0;" was missing (so this
      syscall returned -ENOENT instead of 0)
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      CC: Stephen Hemminger <shemminger@linux-foundation.org>
      CC: John find <linux.kernel@free.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b7aa0bf7
  2. 27 2月, 2007 1 次提交
  3. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  4. 13 2月, 2007 1 次提交
  5. 11 2月, 2007 1 次提交
  6. 09 2月, 2007 2 次提交
    • H
      [PACKET]: Fix skb->cb clobbering between aux and sockaddr · ffbc6111
      Herbert Xu 提交于
      Both aux data and sockaddr tries to use the same buffer which
      obviously doesn't work.  We just happen to have 4 bytes free in
      the skb->cb if you take away the maximum length of sockaddr_ll.
      That's just enough to store the one piece of info from aux data
      that we can't generate at recvmsg(2) time.
      
      This is what the following patch does.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ffbc6111
    • H
      [PACKET]: Add optional checksum computation for recvmsg · 8dc41944
      Herbert Xu 提交于
      This patch is needed to make ISC's DHCP server (and probably other
      DHCP servers/clients using AF_PACKET) to be able to serve another
      client on the same Xen host.
      
      The problem is that packets between different domains on the same
      Xen host only have partial checksums.  Unfortunately this piece of
      information is not passed along in AF_PACKET unless you're using
      the mmap interface.  Since dhcpd doesn't support packet-mmap, UDP
      packets from the same host come out with apparently bogus checksums.
      
      This patch adds a mechanism for AF_PACKET recvmsg(2) to return the
      status along with the packet.  It does so by adding a new cmsg that
      contains this information along with some other relevant data such
      as the original packet length.
      
      I didn't include the time stamp information since there is already
      a cmsg for that.
      
      This patch also changes the mmap code to set the CSUMNOTREADY flag
      on all packets instead of just outoing packets on cooked sockets.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8dc41944
  7. 26 1月, 2007 1 次提交
  8. 25 1月, 2007 1 次提交
    • D
      [AF_PACKET]: Fix BPF handling. · dbcb5855
      David S. Miller 提交于
      This fixes a bug introduced by:
      
      commit fda9ef5d
      Author: Dmitry Mishin <dim@openvz.org>
      Date:   Thu Aug 31 15:28:39 2006 -0700
      
          [NET]: Fix sk->sk_filter field access
      
      sk_run_filter() returns either 0 or an unsigned 32-bit
      length which says how much of the packet to retain.
      If that 32-bit unsigned integer is larger than the packet,
      this is fine we just leave the packet unchanged.
      
      The above commit caused all filter return values which
      were negative when interpreted as a signed integer to
      indicate a packet drop, which is wrong.
      
      Based upon a report and initial patch by Raivis Bucis.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dbcb5855
  9. 07 12月, 2006 1 次提交
    • R
      [NET]: Memory barrier cleanups · e16aa207
      Ralf Baechle 提交于
      I believe all the below memory barriers only matter on SMP so
      therefore the smp_* variant of the barrier should be used.
      
      I'm wondering if the barrier in net/ipv4/inet_timewait_sock.c should be
      dropped entirely.  schedule_work's implementation currently implies a
      memory barrier and I think sane semantics of schedule_work() should imply
      a memory barrier, as needed so the caller shouldn't have to worry.
      It's not quite obvious why the barrier in net/packet/af_packet.c is
      needed; maybe it should be implied through flush_dcache_page?
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e16aa207
  10. 04 12月, 2006 1 次提交
  11. 03 12月, 2006 1 次提交
  12. 23 9月, 2006 2 次提交
  13. 18 9月, 2006 1 次提交
  14. 01 7月, 2006 1 次提交
  15. 24 1月, 2006 1 次提交
  16. 12 1月, 2006 2 次提交
  17. 04 1月, 2006 2 次提交
    • C
      [NET]: Add a dev_ioctl() fallback to sock_ioctl() · b5e5fa5e
      Christoph Hellwig 提交于
      Currently all network protocols need to call dev_ioctl as the default
      fallback in their ioctl implementations.  This patch adds a fallback
      to dev_ioctl to sock_ioctl if the protocol returned -ENOIOCTLCMD.
      This way all the procotol ioctl handlers can be simplified and we don't
      need to export dev_ioctl.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b5e5fa5e
    • E
      [NET]: move struct proto_ops to const · 90ddc4f0
      Eric Dumazet 提交于
      I noticed that some of 'struct proto_ops' used in the kernel may share
      a cache line used by locks or other heavily modified data. (default
      linker alignement is 32 bytes, and L1_CACHE_LINE is 64 or 128 at
      least)
      
      This patch makes sure a 'struct proto_ops' can be declared as const,
      so that all cpus can share all parts of it without false sharing.
      
      This is not mandatory : a driver can still use a read/write structure
      if it needs to (and eventually a __read_mostly)
      
      I made a global stubstitute to change all existing occurences to make
      them const.
      
      This should reduce the possibility of false sharing on SMP, and
      speedup some socket system calls.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90ddc4f0
  18. 07 12月, 2005 1 次提交
  19. 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
  20. 27 9月, 2005 1 次提交
  21. 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
  22. 07 9月, 2005 1 次提交
  23. 30 8月, 2005 2 次提交
  24. 13 7月, 2005 1 次提交
  25. 06 5月, 2005 1 次提交
  26. 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