1. 26 4月, 2007 1 次提交
  2. 13 2月, 2007 1 次提交
  3. 11 2月, 2007 1 次提交
  4. 04 2月, 2007 1 次提交
  5. 14 12月, 2006 2 次提交
  6. 09 12月, 2006 1 次提交
  7. 22 11月, 2006 2 次提交
    • 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
    • D
      WorkStruct: Separate delayable and non-delayable events. · 52bad64d
      David Howells 提交于
      Separate delayable work items from non-delayable work items be splitting them
      into a separate structure (delayed_work), which incorporates a work_struct and
      the timer_list removed from work_struct.
      
      The work_struct struct is huge, and this limits it's usefulness.  On a 64-bit
      architecture it's nearly 100 bytes in size.  This reduces that by half for the
      non-delayable type of event.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      52bad64d
  8. 06 8月, 2006 1 次提交
  9. 24 5月, 2006 1 次提交
  10. 28 3月, 2006 5 次提交
  11. 21 3月, 2006 1 次提交
  12. 10 1月, 2006 1 次提交
  13. 08 9月, 2005 1 次提交
    • B
      [PATCH] sunrpc: cache_register can use wrong module reference · f35279d3
      Bruce Allan 提交于
      When registering an RPC cache, cache_register() always sets the owner as the
      sunrpc module.  However, there are RPC caches owned by other modules.  With
      the incorrect owner setting, the real owning module can be removed potentially
      with an open reference to the cache from userspace.
      
      For example, if one were to stop the nfs server and unmount the nfsd
      filesystem, the nfsd module could be removed eventhough rpc.idmapd had
      references to the idtoname and nametoid caches (i.e.
      /proc/net/rpc/nfs4.<cachename>/channel is still open).  This resulted in a
      system panic on one of our machines when attempting to restart the nfs
      services after reloading the nfsd module.
      
      The following patch adds a 'struct module *owner' field in struct
      cache_detail.  The owner is further assigned to the struct proc_dir_entry
      in cache_register() so that the module cannot be unloaded while user-space
      daemons have an open reference on the associated file under /proc.
      Signed-off-by: NBruce Allan <bwa@us.ibm.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Neil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f35279d3
  14. 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