Doug / smarc-fsl-linux-kernel

29 Sep, 2009

1 commit

  • 925936ebf   tracing: Pushdown the bkl tracepoints calls ... Browse Code »

    Currently we are calling the bkl tracepoint callbacks just before the
    bkl lock/unlock operations, ie the tracepoint call is not inside a
    lock_kernel() function but inside a lock_kernel() macro. Hence the
    bkl trace event header must be included from smp_lock.h. This raises
    some nasty circular header dependencies:

    linux/smp_lock.h -> trace/events/bkl.h -> trace/define_trace.h
    -> trace/ftrace.h -> linux/ftrace_event.h -> linux/hardirq.h
    -> linux/smp_lock.h

    This results in incomplete event declarations, spurious event
    definitions and other kind of funny behaviours.

    This is hardly fixable without ugly workarounds. So instead, we push
    the file name, line number and function name as lock_kernel()
    parameters, so that we only deal with the trace event header from
    lib/kernel_lock.c

    This adds two parameters to lock_kernel() and unlock_kernel() but
    it should be fine wrt to performances because this pair dos not seem
    to be called in fast paths.

    Signed-off-by: Frederic Weisbecker
    Cc: Steven Rostedt
    Cc: Ingo Molnar
    Cc: Li Zefan

    Frederic Weisbecker
     

24 Sep, 2009

1 commit

  • 96a2c464d   tracing/bkl: Add bkl ftrace events ... Browse Code »

    Add two events lock_kernel and unlock_kernel() to trace the bkl uses.
    This opens the door for userspace tools to perform statistics about
    the callsites that use it, dependencies with other locks (by pairing
    the trace with lock events), use with recursivity and so on...

    The {__reacquire,release}_kernel_lock() events are not traced because
    these are called from schedule, thus the sched events are sufficient
    to trace them.

    Example of a trace:

    hald-addon-stor-4152 [000] 165.875501: unlock_kernel: depth: 0, fs/block_dev.c:1358 __blkdev_put()
    hald-addon-stor-4152 [000] 167.832974: lock_kernel: depth: 0, fs/block_dev.c:1167 __blkdev_get()

    How to get the callsites that acquire it recursively:

    cd /debug/tracing/events/bkl
    echo "lock_depth > 0" > filter

    firefox-4951 [001] 206.276967: unlock_kernel: depth: 1, fs/reiserfs/super.c:575 reiserfs_dirty_inode()

    You can also filter by file and/or line.

    v2: Use of FILTER_PTR_STRING attribute for files and lines fields to
    make them traceable.

    Signed-off-by: Frederic Weisbecker
    Cc: Steven Rostedt
    Cc: Li Zefan

    Frederic Weisbecker
     

21 Jun, 2008

1 commit

  • 0b2806768   Add cycle_kernel_lock() ... Browse Code »

    A number of driver functions are so obviously trivial that they do not need
    the big kernel lock - at least not overtly. It turns out that the
    acquisition of the BKL in driver open() functions can perform a sort of
    poor-hacker's serialization function, delaying the open operation until the
    driver is certain to have completed its initialization. Add a simple
    cycle_kernel_lock() function for these cases to make it clear that there is
    no need to *hold* the BKL, just to be sure that we can acquire it.

    Signed-off-by: Jonathan Corbet

    Jonathan Corbet
     

26 Jan, 2008

1 commit

17 Jul, 2007

1 commit

26 Apr, 2006

1 commit

14 Nov, 2005

1 commit

  • f037360f2   [PATCH] m68k: thread_info header cleanup ... Browse Code »

    a) in smp_lock.h #include of sched.h and spinlock.h moved under #ifdef
    CONFIG_LOCK_KERNEL.

    b) interrupt.h now explicitly pulls sched.h (not via smp_lock.h from
    hardirq.h as it used to)

    c) in three more places we need changes to compensate for (a) - one place
    in arch/sparc needs string.h now, hardirq.h needs forward declaration of
    task_struct and preempt.h needs direct include of thread_info.h.

    d) thread_info-related helpers in sched.h and thread_info.h put under
    ifndef __HAVE_THREAD_FUNCTIONS. Obviously safe.

    Signed-off-by: Al Viro
    Signed-off-by: Roman Zippel
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Al Viro
     

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