Eric Lee / smarc-fsl-linux-kernel

10 Sep, 2005

3 commits

  • b835996f6   [PATCH] files: lock-free fd look-up ... Browse Code »

    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: Maneesh Soni
    Signed-off-by: Ravikiran Thirumalai
    Signed-off-by: Dipankar Sarma
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dipankar Sarma
     
  • badf16621   [PATCH] files: break up files struct ... Browse Code »

    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: Dipankar Sarma
    Signed-Off-By: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dipankar Sarma
     
  • ff55fe207   [PATCH] pty_chars_in_buffer oops fix ... Browse Code »

    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: Jason Baron
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jason Baron
     

08 Sep, 2005

1 commit

26 Jun, 2005

1 commit

24 Jun, 2005

1 commit

21 Jun, 2005

1 commit

06 May, 2005

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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!

    Linus Torvalds