• Pekka Paalanen's avatar
    x86: mmiotrace full patch, preview 1 · 0fd0e3da
    Pekka Paalanen authored
    kmmio.c handles the list of mmio probes with callbacks, list of traced
    pages, and attaching into the page fault handler and die notifier. It
    arms, traps and disarms the given pages, this is the core of mmiotrace.
    
    mmio-mod.c is a user interface, hooking into ioremap functions and
    registering the mmio probes. It also decodes the required information
    from trapped mmio accesses via the pre and post callbacks in each probe.
    Currently, hooking into ioremap functions works by redefining the symbols
    of the target (binary) kernel module, so that it calls the traced
    versions of the functions.
    
    The most notable changes done since the last discussion are:
    - kmmio.c is a built-in, not part of the module
    - direct call from fault.c to kmmio.c, removing all dynamic hooks
    - prepare for unregistering probes at any time
    - make kmmio re-initializable and accessible to more than one user
    - rewrite kmmio locking to remove all spinlocks from page fault path
    
    Can I abuse call_rcu() like I do in kmmio.c:unregister_kmmio_probe()
    or is there a better way?
    
    The function called via call_rcu() itself calls call_rcu() again,
    will this work or break? There I need a second grace period for RCU
    after the first grace period for page faults.
    
    Mmiotrace itself (mmio-mod.c) is still a module, I am going to attack
    that next. At some point I will start looking into how to make mmiotrace
    a tracer component of ftrace (thanks for the hint, Ingo). Ftrace should
    make the user space part of mmiotracing as simple as
    'cat /debug/trace/mmio > dump.txt'.
    Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    0fd0e3da
init_task.c 1.43 KB