1. 24 1月, 2008 1 次提交
  2. 23 1月, 2008 1 次提交
  3. 20 10月, 2007 1 次提交
    • P
      pid namespaces: round up the API · a47afb0f
      Pavel Emelianov 提交于
      The set of functions process_session, task_session, process_group and
      task_pgrp is confusing, as the names can be mixed with each other when looking
      at the code for a long time.
      
      The proposals are to
      * equip the functions that return the integer with _nr suffix to
        represent that fact,
      * and to make all functions work with task (not process) by making
        the common prefix of the same name.
      
      For monotony the routines signal_session() and set_signal_session() are
      replaced with task_session_nr() and set_task_session(), especially since they
      are only used with the explicit task->signal dereference.
      Signed-off-by: NPavel Emelianov <xemul@openvz.org>
      Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
      Cc: Kirill Korotaev <dev@openvz.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: Herbert Poetzl <herbert@13thfloor.at>
      Cc: Sukadev Bhattiprolu <sukadev@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a47afb0f
  4. 17 10月, 2007 1 次提交
  5. 11 10月, 2007 1 次提交
    • E
      [NET]: Make the device list and device lookups per namespace. · 881d966b
      Eric W. Biederman 提交于
      This patch makes most of the generic device layer network
      namespace safe.  This patch makes dev_base_head a
      network namespace variable, and then it picks up
      a few associated variables.  The functions:
      dev_getbyhwaddr
      dev_getfirsthwbytype
      dev_get_by_flags
      dev_get_by_name
      __dev_get_by_name
      dev_get_by_index
      __dev_get_by_index
      dev_ioctl
      dev_ethtool
      dev_load
      wireless_process_ioctl
      
      were modified to take a network namespace argument, and
      deal with it.
      
      vlan_ioctl_set and brioctl_set were modified so their
      hooks will receive a network namespace argument.
      
      So basically anthing in the core of the network stack that was
      affected to by the change of dev_base was modified to handle
      multiple network namespaces.  The rest of the network stack was
      simply modified to explicitly use &init_net the initial network
      namespace.  This can be fixed when those components of the network
      stack are modified to handle multiple network namespaces.
      
      For now the ifindex generator is left global.
      
      Fundametally ifindex numbers are per namespace, or else
      we will have corner case problems with migration when
      we get that far.
      
      At the same time there are assumptions in the network stack
      that the ifindex of a network device won't change.  Making
      the ifindex number global seems a good compromise until
      the network stack can cope with ifindex changes when
      you change namespaces, and the like.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      881d966b
  6. 20 7月, 2007 1 次提交
  7. 09 5月, 2007 1 次提交
  8. 04 5月, 2007 1 次提交
  9. 26 4月, 2007 1 次提交
  10. 13 4月, 2007 1 次提交
    • R
      [SPARC]: avoid CHILD_MAX and OPEN_MAX constants · 1d51c69f
      Roland McGrath 提交于
      I don't figure anyone really cares about SunOS syscall emulation, and I
      certainly don't.  But I'm getting rid of uses of the OPEN_MAX and CHILD_MAX
      compile-time constant, and these are almost the only ones.  OPEN_MAX is a
      bogus constant with no meaning about anything.  The RLIMIT_NOFILE resource
      limit is what sysconf (_SC_OPEN_MAX) actually wants to return.
      
      The CHILD_MAX cases weren't actually using anything I want to get rid of,
      but I noticed that they are there and are wrong too.  The CHILD_MAX value
      is not really unlimited as a -1 return from sysconf indicates.  The
      RLIMIT_NPROC resource limit is what sysconf (_SC_CHILD_MAX) wants to return.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d51c69f
  11. 13 2月, 2007 1 次提交
  12. 09 12月, 2006 2 次提交
    • J
      [PATCH] struct path: convert sparc64 · 1250ca4c
      Josef Sipek 提交于
      Signed-off-by: NJosef Sipek <jsipek@fsl.cs.sunysb.edu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1250ca4c
    • P
      [PATCH] tty: ->signal->tty locking · 24ec839c
      Peter Zijlstra 提交于
      Fix the locking of signal->tty.
      
      Use ->sighand->siglock to protect ->signal->tty; this lock is already used
      by most other members of ->signal/->sighand.  And unless we are 'current'
      or the tasklist_lock is held we need ->siglock to access ->signal anyway.
      
      (NOTE: sys_unshare() is broken wrt ->sighand locking rules)
      
      Note that tty_mutex is held over tty destruction, so while holding
      tty_mutex any tty pointer remains valid.  Otherwise the lifetime of ttys
      are governed by their open file handles.  This leaves some holes for tty
      access from signal->tty (or any other non file related tty access).
      
      It solves the tty SLAB scribbles we were seeing.
      
      (NOTE: the change from group_send_sig_info to __group_send_sig_info needs to
             be examined by someone familiar with the security framework, I think
             it is safe given the SEND_SIG_PRIV from other __group_send_sig_info
             invocations)
      
      [schwidefsky@de.ibm.com: 3270 fix]
      [akpm@osdl.org: various post-viro fixes]
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NAlan Cox <alan@redhat.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: James Morris <jmorris@namei.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Jan Kara <jack@ucw.cz>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      24ec839c
  13. 03 10月, 2006 1 次提交
    • D
      [PATCH] VFS: Make filldir_t and struct kstat deal in 64-bit inode numbers · afefdbb2
      David Howells 提交于
      These patches make the kernel pass 64-bit inode numbers internally when
      communicating to userspace, even on a 32-bit system.  They are required
      because some filesystems have intrinsic 64-bit inode numbers: NFS3+ and XFS
      for example.  The 64-bit inode numbers are then propagated to userspace
      automatically where the arch supports it.
      
      Problems have been seen with userspace (eg: ld.so) using the 64-bit inode
      number returned by stat64() or getdents64() to differentiate files, and
      failing because the 64-bit inode number space was compressed to 32-bits, and
      so overlaps occur.
      
      This patch:
      
      Make filldir_t take a 64-bit inode number and struct kstat carry a 64-bit
      inode number so that 64-bit inode numbers can be passed back to userspace.
      
      The stat functions then returns the full 64-bit inode number where
      available and where possible.  If it is not possible to represent the inode
      number supplied by the filesystem in the field provided by userspace, then
      error EOVERFLOW will be issued.
      
      Similarly, the getdents/readdir functions now pass the full 64-bit inode
      number to userspace where possible, returning EOVERFLOW instead when a
      directory entry is encountered that can't be properly represented.
      
      Note that this means that some inodes will not be stat'able on a 32-bit
      system with old libraries where they were before - but it does mean that
      there will be no ambiguity over what a 32-bit inode number refers to.
      
      Note similarly that directory scans may be cut short with an error on a
      32-bit system with old libraries where the scan would work before for the
      same reasons.
      
      It is judged unlikely that this situation will occur because modern glibc
      uses 64-bit capable versions of stat and getdents class functions
      exclusively, and that older systems are unlikely to encounter
      unrepresentable inode numbers anyway.
      
      [akpm: alpha build fix]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      afefdbb2
  14. 02 10月, 2006 1 次提交
  15. 30 9月, 2006 1 次提交
  16. 26 9月, 2006 1 次提交
  17. 01 7月, 2006 1 次提交
  18. 27 6月, 2006 3 次提交
  19. 24 6月, 2006 1 次提交
  20. 23 6月, 2006 1 次提交
  21. 20 3月, 2006 1 次提交
  22. 05 3月, 2006 1 次提交
  23. 08 2月, 2006 1 次提交
  24. 19 1月, 2006 1 次提交
  25. 12 1月, 2006 1 次提交
  26. 23 12月, 2005 1 次提交
  27. 28 10月, 2005 1 次提交
  28. 10 9月, 2005 3 次提交
  29. 30 8月, 2005 1 次提交
  30. 10 8月, 2005 1 次提交
    • A
      [NET]: Fix memory leak in sys_{send,recv}msg() w/compat · d64d3873
      Andrew Morton 提交于
      From: Dave Johnson <djohnson+linux-kernel@sw.starentnetworks.com>
      
      sendmsg()/recvmsg() syscalls from o32/n32 apps to a 64bit kernel will
      cause a kernel memory leak if iov_len > UIO_FASTIOV for each syscall!
      
      This is because both sys_sendmsg() and verify_compat_iovec() kmalloc a
      new iovec structure.  Only the one from sys_sendmsg() is free'ed.
      
      I wrote a simple test program to confirm this after identifying the
      problem:
      
      http://davej.org/programs/testsendmsg.c
      
      Note that the below fix will break solaris_sendmsg()/solaris_recvmsg() as
      it also calls verify_compat_iovec() but expects it to malloc internally.
      
      [ I fixed that. -DaveM ]
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d64d3873
  31. 11 7月, 2005 1 次提交
  32. 22 6月, 2005 1 次提交
  33. 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