)]}'
{
  "log": [
    {
      "commit": "9edddaa200df18e08fe0cf21036e8ae467b1363c",
      "tree": "26f5319fac24fb6c76b1276b19725caeb5ec24bc",
      "parents": [
        "8182ec49a73729334f5a6c65a607ba7009ebd6d6"
      ],
      "author": {
        "name": "Ananth N Mavinakayanahalli",
        "email": "ananth@in.ibm.com",
        "time": "Tue Mar 04 14:28:37 2008 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@woody.linux-foundation.org",
        "time": "Tue Mar 04 16:35:11 2008 -0800"
      },
      "message": "Kprobes: indicate kretprobe support in Kconfig\n\nAdd CONFIG_HAVE_KRETPROBES to the arch/\u003carch\u003e/Kconfig file for relevant\narchitectures with kprobes support.  This facilitates easy handling of\nin-kernel modules (like samples/kprobes/kretprobe_example.c) that depend on\nkretprobes being present in the kernel.\n\nThanks to Sam Ravnborg for helping make the patch more lean.\n\nPer Mathieu\u0027s suggestion, added CONFIG_KRETPROBES and fixed up dependencies.\n\nSigned-off-by: Ananth N Mavinakayanahalli \u003cananth@in.ibm.com\u003e\nAcked-by: Mathieu Desnoyers \u003cmathieu.desnoyers@polymtl.ca\u003e\nAcked-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    },
    {
      "commit": "796969104cab0d454dbc792ad0d12a4f365a8564",
      "tree": "214eebbe0c8cdee597184feb365c60b574650f6a",
      "parents": [
        "785d3cd286f0bf67d1bf692559b9ae5de12678f5"
      ],
      "author": {
        "name": "Nicolas Pitre",
        "email": "nico@cam.org",
        "time": "Mon Dec 03 17:22:36 2007 -0500"
      },
      "committer": {
        "name": "Russell King",
        "email": "rmk+kernel@arm.linux.org.uk",
        "time": "Sat Jan 26 15:25:17 2008 +0000"
      },
      "message": "ARM kprobes: special hook for the kprobes breakpoint handler\n\nThe kprobes code is already able to cope with reentrant probes, so its\nhandler must be called outside of the region protected by undef_lock.\n\nIf ever this lock is released when handlers are called then this commit\ncould be reverted.\n\nSigned-off-by: Nicolas Pitre \u003cnico@marvell.com\u003e\n"
    },
    {
      "commit": "24ba613c9d6cad315f484e658288db152f1dc447",
      "tree": "0a94ff96c77ccf7e0415bd2bc76ab400468c5e6e",
      "parents": [
        "35aa1df4328340f38edc46f00837f08d33d49f63"
      ],
      "author": {
        "name": "Abhishek Sagar",
        "email": "sagar.abhishek@gmail.com",
        "time": "Mon Jun 11 22:20:10 2007 +0000"
      },
      "committer": {
        "name": "Russell King",
        "email": "rmk+kernel@arm.linux.org.uk",
        "time": "Sat Jan 26 15:25:16 2008 +0000"
      },
      "message": "ARM kprobes: core code\n\nThis is a full implementation of Kprobes including Jprobes and\nKretprobes support.\n\nThis ARM implementation does not follow the usual kprobes double-\nexception model. The traditional model is where the initial kprobes\nbreakpoint calls kprobe_handler(), which returns from exception to\nexecute the instruction in its original context, then immediately\nre-enters after a second breakpoint (or single-stepping exception)\ninto post_kprobe_handler(), each time the probe is hit..  The ARM\nimplementation only executes one kprobes exception per hit, so no\npost_kprobe_handler() phase. All side-effects from the kprobe\u0027d\ninstruction are resolved before returning from the initial exception.\nAs a result, all instructions are _always_ effectively boosted\nregardless of the type of instruction, and even regardless of whether\nor not there is a post-handler for the probe.\n\nSigned-off-by: Abhishek Sagar \u003csagar.abhishek@gmail.com\u003e\nSigned-off-by: Quentin Barnes \u003cqbarnes@gmail.com\u003e\nSigned-off-by: Nicolas Pitre \u003cnico@marvell.com\u003e\n"
    },
    {
      "commit": "35aa1df4328340f38edc46f00837f08d33d49f63",
      "tree": "8ed273b1d39462282fadd4c854f17bf545024528",
      "parents": [
        "9b73e76f3cf63379dcf45fcd4f112f5812418d0a"
      ],
      "author": {
        "name": "Quentin Barnes",
        "email": "qbarnes@gmail.com",
        "time": "Mon Jun 11 22:20:10 2007 +0000"
      },
      "committer": {
        "name": "Russell King",
        "email": "rmk+kernel@arm.linux.org.uk",
        "time": "Sat Jan 26 15:25:16 2008 +0000"
      },
      "message": "ARM kprobes: instruction single-stepping support\n\nThis is the code implementing instruction single-stepping for kprobes\non ARM.\n\nTo get around the limitation of no Next-PC and no hardware single-\nstepping, all kprobe\u0027d instructions are split into three camps:\nsimulation, emulation, and rejected. \"Simulated\" instructions are\nthose instructions which behavior is reproduced by straight C code.\n\"Emulated\" instructions are ones that are copied, slightly altered\nand executed directly in the instruction slot to reproduce their\nbehavior.  \"Rejected\" instructions are ones that could be simulated,\nbut work hasn\u0027t been put into simulating them. These instructions\nshould be very rare, if not unencountered, in the kernel. If ever\nneeded, code could be added to simulate them.\n\nOne might wonder why this and the ptrace singlestep facility are not\nsharing some code.  Both approaches are fundamentally different because\nthe ptrace code regains control after the stepped instruction by installing\na breakpoint after the instruction itself, and possibly at the location\nwhere the instruction might be branching to, instead of simulating or\nemulating the target instruction.\n\nThe ptrace approach isn\u0027t suitable for kprobes because the breakpoints\nwould have to be moved back, and the icache flushed, everytime the\nprobe is hit to let normal code execution resume, which would have a\nsignificant performance impact. It is also racy on SMP since another\nCPU could, with the right timing, sail through the probe point without\nbeing caught.  Because ptrace single-stepping always result in a\ndifferent process to be scheduled, the concern for performance is much\nless significant.\n\nOn the other hand, the kprobes approach isn\u0027t (currently) suitable for\nptrace because it has no provision for proper user space memory\nprotection and translation, and even if that was implemented, the gain\nwouldn\u0027t be worth the added complexity in the ptrace path compared to\nthe current approach.\n\nSo, until kprobes does support user space, both kprobes and ptrace are\nbest kept independent and separate.\n\nSigned-off-by: Quentin Barnes \u003cqbarnes@gmail.com\u003e\nSigned-off-by: Abhishek Sagar \u003csagar.abhishek@gmail.com\u003e\nSigned-off-by: Nicolas Pitre \u003cnico@marvell.com\u003e\n"
    }
  ]
}