1. 29 4月, 2008 5 次提交
  2. 09 2月, 2008 3 次提交
    • P
      IPC: make struct ipc_ids static in ipc_namespace · ed2ddbf8
      Pierre Peiffer 提交于
      Each ipc_namespace contains a table of 3 pointers to struct ipc_ids (3 for
      msg, sem and shm, structure used to store all ipcs) These 'struct ipc_ids'
      are dynamically allocated for each icp_namespace as the ipc_namespace
      itself (for the init namespace, they are initialized with pointers to
      static variables instead)
      
      It is so for historical reason: in fact, before the use of idr to store the
      ipcs, the ipcs were stored in tables of variable length, depending of the
      maximum number of ipc allowed.  Now, these 'struct ipc_ids' have a fixed
      size.  As they are allocated in any cases for each new ipc_namespace, there
      is no gain of memory in having them allocated separately of the struct
      ipc_namespace.
      
      This patch proposes to make this table static in the struct ipc_namespace.
      Thus, we can allocate all in once and get rid of all the code needed to
      allocate and free these ipc_ids separately.
      Signed-off-by: NPierre Peiffer <pierre.peiffer@bull.net>
      Acked-by: NCedric Le Goater <clg@fr.ibm.com>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Cc: Nadia Derbey <Nadia.Derbey@bull.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ed2ddbf8
    • P
      ipc: uninline some code from util.h · b2d75cdd
      Pavel Emelyanov 提交于
      ipc_lock_check_down(), ipc_lock_check() and ipcget() seem too large to be
      inline.  Besides, they give no optimization being inline as they perform
      calls inside in any case.
      
      Moving them into ipc/util.c saves 500 bytes of vmlinux and shortens IPC
      internal API.
      
      $ ./scripts/bloat-o-meter vmlinux-orig vmlinux
      add/remove: 3/2 grow/shrink: 0/10 up/down: 490/-989 (-499)
      function                                     old     new   delta
      ipcget                                         -     392    +392
      ipc_lock_check_down                            -      49     +49
      ipc_lock_check                                 -      49     +49
      sys_semget                                   119     105     -14
      sys_shmget                                   108      86     -22
      sys_msgget                                   100      78     -22
      do_msgsnd                                    665     631     -34
      do_msgrcv                                    680     644     -36
      do_shmat                                     771     733     -38
      sys_msgctl                                  1302    1229     -73
      ipcget_new                                    80       -     -80
      sys_semtimedop                              1534    1452     -82
      sys_semctl                                  2034    1922    -112
      sys_shmctl                                  1919    1765    -154
      ipcget_public                                322       -    -322
      
      The ipcget() growth is the result of gcc inlining of currently static
      ipcget_new/_public.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Cc: Nadia Derbey <Nadia.Derbey@bull.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b2d75cdd
    • P
      namespaces: move the IPC namespace under IPC_NS option · ae5e1b22
      Pavel Emelyanov 提交于
      Currently the IPC namespace management code is spread over the ipc/*.c files.
      I moved this code into ipc/namespace.c file which is compiled out when needed.
      
      The linux/ipc_namespace.h file is used to store the prototypes of the
      functions in namespace.c and the stubs for NAMESPACES=n case.  This is done
      so, because the stub for copy_ipc_namespace requires the knowledge of the
      CLONE_NEWIPC flag, which is in sched.h.  But the linux/ipc.h file itself in
      included into many many .c files via the sys.h->sem.h sequence so adding the
      sched.h into it will make all these .c depend on sched.h which is not that
      good.  On the other hand the knowledge about the namespaces stuff is required
      in 4 .c files only.
      
      Besides, this patch compiles out some auxiliary functions from ipc/sem.c,
      msg.c and shm.c files.  It turned out that moving these functions into
      namespaces.c is not that easy because they use many other calls and macros
      from the original file.  Moving them would make this patch complicated.  On
      the other hand all these functions can be consolidated, so I will send a
      separate patch doing this a bit later.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Acked-by: NSerge Hallyn <serue@us.ibm.com>
      Cc: Cedric Le Goater <clg@fr.ibm.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Herbert Poetzl <herbert@13thfloor.at>
      Cc: Kirill Korotaev <dev@sw.ru>
      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>
      ae5e1b22
  3. 07 2月, 2008 1 次提交
  4. 20 10月, 2007 9 次提交
  5. 17 7月, 2007 1 次提交
  6. 09 5月, 2007 2 次提交
  7. 28 3月, 2007 1 次提交
  8. 13 2月, 2007 2 次提交
  9. 12 2月, 2007 1 次提交
  10. 22 11月, 2006 1 次提交
    • D
      WorkStruct: Pass the work_struct pointer instead of context data · 65f27f38
      David Howells 提交于
      Pass the work_struct pointer to the work function rather than context data.
      The work function can use container_of() to work out the data.
      
      For the cases where the container of the work_struct may go away the moment the
      pending bit is cleared, it is made possible to defer the release of the
      structure by deferring the clearing of the pending bit.
      
      To make this work, an extra flag is introduced into the management side of the
      work_struct.  This governs auto-release of the structure upon execution.
      
      Ordinarily, the work queue executor would release the work_struct for further
      scheduling or deallocation by clearing the pending bit prior to jumping to the
      work function.  This means that, unless the driver makes some guarantee itself
      that the work_struct won't go away, the work function may not access anything
      else in the work_struct or its container lest they be deallocated..  This is a
      problem if the auxiliary data is taken away (as done by the last patch).
      
      However, if the pending bit is *not* cleared before jumping to the work
      function, then the work function *may* access the work_struct and its container
      with no problems.  But then the work function must itself release the
      work_struct by calling work_release().
      
      In most cases, automatic release is fine, so this is the default.  Special
      initiators exist for the non-auto-release case (ending in _NAR).
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      65f27f38
  11. 04 11月, 2006 1 次提交
    • P
      [PATCH] Fix ipc entries removal · c7e12b83
      Pavel Emelianov 提交于
      Fix two issuses related to ipc_ids->entries freeing.
      
      1. When freeing ipc namespace we need to free entries allocated
         with ipc_init_ids().
      
      2. When removing old entries in grow_ary() ipc_rcu_putref()
         may be called on entries set to &ids->nullentry earlier in
         ipc_init_ids().
         This is almost impossible without namespaces, but with
         them this situation becomes possible.
      
      Found during OpenVZ testing after obvious leaks in beancounters.
      Signed-off-by: NPavel Emelianov <xemul@openvz.org>
      Cc: Kirill Korotaev <dev@openvz.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c7e12b83
  12. 02 10月, 2006 1 次提交
  13. 01 7月, 2006 1 次提交
  14. 01 5月, 2006 1 次提交
    • S
      [PATCH] Rework of IPC auditing · 073115d6
      Steve Grubb 提交于
      1) The audit_ipc_perms() function has been split into two different
      functions:
              - audit_ipc_obj()
              - audit_ipc_set_perm()
      
      There's a key shift here...  The audit_ipc_obj() collects the uid, gid,
      mode, and SElinux context label of the current ipc object.  This
      audit_ipc_obj() hook is now found in several places.  Most notably, it
      is hooked in ipcperms(), which is called in various places around the
      ipc code permforming a MAC check.  Additionally there are several places
      where *checkid() is used to validate that an operation is being
      performed on a valid object while not necessarily having a nearby
      ipcperms() call.  In these locations, audit_ipc_obj() is called to
      ensure that the information is captured by the audit system.
      
      The audit_set_new_perm() function is called any time the permissions on
      the ipc object changes.  In this case, the NEW permissions are recorded
      (and note that an audit_ipc_obj() call exists just a few lines before
      each instance).
      
      2) Support for an AUDIT_IPC_SET_PERM audit message type.  This allows
      for separate auxiliary audit records for normal operations on an IPC
      object and permissions changes.  Note that the same struct
      audit_aux_data_ipcctl is used and populated, however there are separate
      audit_log_format statements based on the type of the message.  Finally,
      the AUDIT_IPC block of code in audit_free_aux() was extended to handle
      aux messages of this new type.  No more mem leaks I hope ;-)
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      073115d6
  15. 18 4月, 2006 1 次提交
  16. 01 4月, 2006 1 次提交
  17. 27 3月, 2006 1 次提交
  18. 15 1月, 2006 1 次提交
  19. 12 1月, 2006 1 次提交
  20. 07 11月, 2005 1 次提交
  21. 08 9月, 2005 1 次提交
  22. 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