1. 30 Oct, 2006 1 commit
  2. 28 Sep, 2006 1 commit
  3. 21 Jul, 2006 1 commit
  4. 30 Jun, 2006 1 commit
  5. 28 Mar, 2006 1 commit
    • Petr Vandrovec's avatar
      [NET]: Fix ipx/econet/appletalk/irda ioctl crashes · f6c90b71
      Petr Vandrovec authored
      
      Fix kernel oopses whenever somebody issues compatible ioctl on AppleTalk,
      Econet, IPX or IRDA socket.  For AppleTalk/Econet/IRDA it restores state
      in which these sockets were before compat_ioctl was introduced to the socket
      ops, for IPX it implements support for 4 ioctls which were not implemented
      before - as these ioctls use structures which match between 32bit and 64bit
      userspace, no special code is needed, just call 64bit ioctl handler.
      Signed-off-by: default avatarPetr Vandrovec <petr@vandrovec.name>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6c90b71
  6. 11 Jan, 2006 1 commit
  7. 03 Jan, 2006 2 commits
    • Christoph Hellwig's avatar
      [NET]: Add a dev_ioctl() fallback to sock_ioctl() · b5e5fa5e
      Christoph Hellwig authored
      
      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: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b5e5fa5e
    • Eric Dumazet's avatar
      [NET]: move struct proto_ops to const · 90ddc4f0
      Eric Dumazet authored
      
      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: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90ddc4f0
  8. 27 Sep, 2005 1 commit
    • Oliver Dawid's avatar
      [APPLETALK]: Fix broadcast bug. · 64233bff
      Oliver Dawid authored
      From: Oliver Dawid <oliver@helios.de>
      
      we found a bug in net/appletalk/ddp.c concerning broadcast packets. In 
      kernel 2.4 it was working fine. The bug first occured 4 years ago when 
      switching to new SNAP layer handling. This bug can be splitted up into a 
      sending(1) and reception(2) problem:
      
      Sending(1)
      In kernel 2.4 broadcast packets were sent to a matching ethernet device 
      and atalk_rcv() was called to receive it as "loopback" (so loopback 
      packets were shortcutted and handled in DDP layer).
      
      When switching to the new SNAP structure, this shortcut was removed and 
      the loopback packet was send to SNAP layer. The author forgot to replace 
      the remote device pointer by the loopback device pointer before sending 
      the packet to SNAP layer (by calling ddp_dl->request() ) therfor the 
      packet was not sent back by underlying layers to ddp's atalk_rcv().
      
      Reception(2)
      In atalk_rcv() a packet received by this loopback mechanism contains now 
      the (rigth) loopback device pointer (in K...
      64233bff
  9. 29 Aug, 2005 2 commits
  10. 20 Jun, 2005 1 commit
  11. 20 Apr, 2005 1 commit
  12. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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