1. 07 10月, 2009 1 次提交
  2. 01 10月, 2009 1 次提交
  3. 04 12月, 2008 1 次提交
    • D
      atm: 32-bit ioctl compatibility · 8865c418
      David Woodhouse 提交于
      We lack compat ioctl support through most of the ATM code. This patch
      deals with most of it, and I can now at least use BR2684 and PPPoATM
      with 32-bit userspace.
      
      I haven't added a .compat_ioctl method to struct atm_ioctl, because
      AFAICT none of the current users need any conversion -- so we can just
      call the ->ioctl() method in every case. I looked at br2684, clip, lec,
      mpc, pppoatm and atmtcp.
      
      In svc_compat_ioctl() the only mangling which is needed is to change
      COMPAT_ATM_ADDPARTY to ATM_ADDPARTY. Although it's defined as
      	_IOW('a', ATMIOC_SPECIAL+4,struct atm_iobuf)
      it doesn't actually _take_ a struct atm_iobuf as an argument -- it takes
      a struct sockaddr_atmsvc, which _is_ the same between 32-bit and 64-bit
      code, so doesn't need conversion.
      
      Almost all of vcc_ioctl() would have been identical, so I converted that
      into a core do_vcc_ioctl() function with an 'int compat' argument.
      
      I've done the same with atm_dev_ioctl(), where there _are_ a few
      differences, but still it's relatively contained and there would
      otherwise have been a lot of duplication.
      
      I haven't done any of the actual device-specific ioctls, although I've
      added a compat_ioctl method to struct atmdev_ops.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8865c418
  4. 11 10月, 2007 1 次提交
    • E
      [NET]: Make socket creation namespace safe. · 1b8d7ae4
      Eric W. Biederman 提交于
      This patch passes in the namespace a new socket should be created in
      and has the socket code do the appropriate reference counting.  By
      virtue of this all socket create methods are touched.  In addition
      the socket create methods are modified so that they will fail if
      you attempt to create a socket in a non-default network namespace.
      
      Failing if we attempt to create a socket outside of the default
      network namespace ensures that as we incrementally make the network stack
      network namespace aware we will not export functionality that someone
      has not audited and made certain is network namespace safe.
      Allowing us to partially enable network namespaces before all of the
      exotic protocols are supported.
      
      Any protocol layers I have missed will fail to compile because I now
      pass an extra parameter into the socket creation code.
      
      [ Integrated AF_IUCV build fixes from Andrew Morton... -DaveM ]
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b8d7ae4
  5. 11 2月, 2007 1 次提交
  6. 01 7月, 2006 1 次提交
  7. 04 1月, 2006 1 次提交
    • 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
  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