1. 07 11月, 2005 1 次提交
  2. 31 10月, 2005 1 次提交
  3. 29 10月, 2005 1 次提交
  4. 10 9月, 2005 3 次提交
    • D
      [PATCH] files: lock-free fd look-up · b835996f
      Dipankar Sarma 提交于
      With the use of RCU in files structure, the look-up of files using fds can now
      be lock-free.  The lookup is protected by rcu_read_lock()/rcu_read_unlock().
      This patch changes the readers to use lock-free lookup.
      Signed-off-by: NManeesh Soni <maneesh@in.ibm.com>
      Signed-off-by: NRavikiran Thirumalai <kiran_th@gmail.com>
      Signed-off-by: NDipankar Sarma <dipankar@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b835996f
    • D
      [PATCH] files: break up files struct · badf1662
      Dipankar Sarma 提交于
      In order for the RCU to work, the file table array, sets and their sizes must
      be updated atomically.  Instead of ensuring this through too many memory
      barriers, we put the arrays and their sizes in a separate structure.  This
      patch takes the first step of putting the file table elements in a separate
      structure fdtable that is embedded withing files_struct.  It also changes all
      the users to refer to the file table using files_fdtable() macro.  Subsequent
      applciation of RCU becomes easier after this.
      Signed-off-by: NDipankar Sarma <dipankar@in.ibm.com>
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      badf1662
    • J
      [PATCH] pty_chars_in_buffer oops fix · ff55fe20
      Jason Baron 提交于
      The idea of this patch is to lock both sides of a ptmx/pty pair during line
      discipline changing.  This is needed to ensure that say a poll on one side of
      the pty doesn't occur while the line discipline is actively being changed.
      This resulted in an oops reported on lkml, see:
      
      	http://marc.theaimsgroup.com/?l=linux-kernel&m=111342171410005&w=2
      
      A 'hacky' approach was previously implmemented which served to eliminate the
      poll vs.  line discipline changing race.  However, this patch takes a more
      general approach to the issue.  The patch only adds locking on a less often
      used path, the line-discipline changing path, as opposed to locking the
      ptmx/pty pair on read/write/poll paths.
      
      The patch below, takes both ldisc locks in either order b/c the locks are both
      taken under the same spinlock().  I thought about locking the ptmx/pty
      separately, such as master always first but that introduces a 3 way deadlock.
      For example, process 1 does a blocking read on the slave side.  Then, process
      2 does an ldisc change on the slave side, which acquires the master ldisc lock
      but not the slave's.  Finally, process 3 does a write which blocks on the
      process 2's ldisc reference.
      
      This patch does introduce some changes in semantics.  For example, a line
      discipline change on side 'a' of a ptmx/pty pair, will now wait for a
      read/write to complete on the other side, or side 'b'.  The current behavior
      is to simply wait for any read/writes on only side 'a', not both sides 'a' and
      'b'.  I think this behavior makes sense, but I wanted to point it out.
      
      I've tested the patch with a bunch of read/write/poll while changing the line
      discipline out from underneath.
      
      This patch obviates the need for the above "hide the problem" patch.
      Signed-off-by: NJason Baron <jbaron@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ff55fe20
  5. 08 9月, 2005 1 次提交
  6. 26 6月, 2005 1 次提交
  7. 24 6月, 2005 1 次提交
  8. 21 6月, 2005 1 次提交
  9. 06 5月, 2005 1 次提交
  10. 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