Eric Lee / smarc-fsl-linux-kernel

12 Dec, 2011

1 commit

21 Aug, 2010

1 commit

20 Aug, 2010

1 commit

14 Apr, 2010

1 commit

  • 50aec0024   rcu: Update docs for rcu_access_pointer and rcu_dereference_protected ... Browse Code »

    Update examples and lists of APIs to include these new
    primitives.

    Signed-off-by: Paul E. McKenney
    Cc: laijs@cn.fujitsu.com
    Cc: dipankar@in.ibm.com
    Cc: mathieu.desnoyers@polymtl.ca
    Cc: josh@joshtriplett.org
    Cc: dvhltc@us.ibm.com
    Cc: niv@us.ibm.com
    Cc: peterz@infradead.org
    Cc: rostedt@goodmis.org
    Cc: Valdis.Kletnieks@vt.edu
    Cc: dhowells@redhat.com
    Cc: eric.dumazet@gmail.com
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Paul E. McKenney
     

25 Feb, 2010

1 commit

  • c598a070b   rcu: Documentation update for CONFIG_PROVE_RCU ... Browse Code »

    Adds a lockdep.txt file and updates checklist.txt and
    whatisRCU.txt to reflect the new lockdep-enabled capabilities of
    RCU.

    Signed-off-by: Paul E. McKenney
    Cc: laijs@cn.fujitsu.com
    Cc: dipankar@in.ibm.com
    Cc: mathieu.desnoyers@polymtl.ca
    Cc: josh@joshtriplett.org
    Cc: dvhltc@us.ibm.com
    Cc: niv@us.ibm.com
    Cc: peterz@infradead.org
    Cc: rostedt@goodmis.org
    Cc: Valdis.Kletnieks@vt.edu
    Cc: dhowells@redhat.com
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Paul E. McKenney
     

16 Jan, 2010

1 commit

  • 4c54005ca   rcu: 1Q2010 update for RCU documentation ... Browse Code »

    Add expedited functions. Review documentation and update
    obsolete verbiage. Also fix the advice for the RCU CPU-stall
    kernel configuration parameter, and document RCU CPU-stall
    warnings.

    Signed-off-by: Paul E. McKenney
    Cc: laijs@cn.fujitsu.com
    Cc: dipankar@in.ibm.com
    Cc: mathieu.desnoyers@polymtl.ca
    Cc: josh@joshtriplett.org
    Cc: dvhltc@us.ibm.com
    Cc: niv@us.ibm.com
    Cc: peterz@infradead.org
    Cc: rostedt@goodmis.org
    Cc: Valdis.Kletnieks@vt.edu
    Cc: dhowells@redhat.com
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Paul E. McKenney
     

03 Jul, 2009

1 commit

  • 240ebbf81   rcu: Add synchronize_sched_expedited() rcutorture doc + updates ... Browse Code »

    This patch updates the rcutorture documentation to include
    updated output format. It also brings the RCU documentation up
    to date.

    Signed-off-by: Paul E. McKenney
    Cc: akpm@linux-foundation.org
    Cc: torvalds@linux-foundation.org
    Cc: davem@davemloft.net
    Cc: dada1@cosmosbay.com
    Cc: zbr@ioremap.net
    Cc: jeff.chua.linux@gmail.com
    Cc: paulus@samba.org
    Cc: laijs@cn.fujitsu.com
    Cc: jengelh@medozas.de
    Cc: r000n@r000n.net
    Cc: benh@kernel.crashing.org
    Cc: mathieu.desnoyers@polymtl.ca
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Paul E. McKenney
     

11 Mar, 2009

1 commit

  • 0612ea00a   rcu: documentation 1Q09 update ... Browse Code »

    Update the RCU documentation to call out the need for callers of
    primitives like call_rcu() and synchronize_rcu() to prevent subsequent RCU
    readers from hazard.

    Signed-off-by: Paul E. McKenney
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul E. McKenney
     

15 Aug, 2008

1 commit

19 May, 2008

1 commit

17 Jul, 2007

1 commit

04 Oct, 2006

1 commit

  • 621934ee7   [PATCH] srcu-3: RCU variant permitting read-side blocking ... Browse Code »

    Updated patch adding a variant of RCU that permits sleeping in read-side
    critical sections. SRCU is as follows:

    o Each use of SRCU creates its own srcu_struct, and each
    srcu_struct has its own set of grace periods. This is
    critical, as it prevents one subsystem with a blocking
    reader from holding up SRCU grace periods for other
    subsystems.

    o The SRCU primitives (srcu_read_lock(), srcu_read_unlock(),
    and synchronize_srcu()) all take a pointer to a srcu_struct.

    o The SRCU primitives must be called from process context.

    o srcu_read_lock() returns an int that must be passed to
    the matching srcu_read_unlock(). Realtime RCU avoids the
    need for this by storing the state in the task struct,
    but SRCU needs to allow a given code path to pass through
    multiple SRCU domains -- storing state in the task struct
    would therefore require either arbitrary space in the
    task struct or arbitrary limits on SRCU nesting. So I
    kicked the state-storage problem up to the caller.

    Of course, it is not permitted to call synchronize_srcu()
    while in an SRCU read-side critical section.

    o There is no call_srcu(). It would not be hard to implement
    one, but it seems like too easy a way to OOM the system.
    (Hey, we have enough trouble with call_rcu(), which does
    -not- permit readers to sleep!!!) So, if you want it,
    please tell me why...

    [josht@us.ibm.com: sparse notation]
    Signed-off-by: Paul E. McKenney
    Signed-off-by: Josh Triplett
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul E. McKenney
     

26 Jun, 2006

1 commit

  • 165d6c78e   [PATCH] RCU documentation: self-limiting updates and call_rcu() ... Browse Code »

    An update to the RCU documentation calling out the
    self-limiting-update-rate advantages of synchronize_rcu(), and describing
    how to use call_rcu() in a way that results in self-limiting updates.
    Self-limiting updates are important to avoiding RCU-induced OOM in face of
    denial-of-service attacks.

    Signed-off-by: Paul E. McKenney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul E. McKenney
     

02 Feb, 2006

1 commit

11 Sep, 2005

1 commit

01 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