)]}'
{
  "commit": "19a493ce62798dbafb8983beb242d5e3f3108407",
  "tree": "1ca1a8ec1abc0267456acb4740c76758f32fa156",
  "parents": [
    "69973b830859bc6529a7a0468ba0d80ee5117826"
  ],
  "author": {
    "name": "Paolo Bonzini",
    "email": "pbonzini@redhat.com",
    "time": "Wed May 31 14:03:11 2017 +0200"
  },
  "committer": {
    "name": "Paul E. McKenney",
    "email": "paulmck@linux.vnet.ibm.com",
    "time": "Mon Jun 12 08:33:45 2017 -0700"
  },
  "message": "srcu: Allow use of Classic SRCU from both process and interrupt context\n\nLinu Cherian reported a WARN in cleanup_srcu_struct() when shutting\ndown a guest running iperf on a VFIO assigned device.  This happens\nbecause irqfd_wakeup() calls srcu_read_lock(\u0026kvm-\u003eirq_srcu) in interrupt\ncontext, while a worker thread does the same inside kvm_set_irq().  If the\ninterrupt happens while the worker thread is executing __srcu_read_lock(),\nupdates to the Classic SRCU -\u003elock_count[] field or the Tree SRCU\n-\u003esrcu_lock_count[] field can be lost.\n\nThe docs say you are not supposed to call srcu_read_lock() and\nsrcu_read_unlock() from irq context, but KVM interrupt injection happens\nfrom (host) interrupt context and it would be nice if SRCU supported the\nuse case.  KVM is using SRCU here not really for the \"sleepable\" part,\nbut rather due to its IPI-free fast detection of grace periods.  It is\ntherefore not desirable to switch back to RCU, which would effectively\nrevert commit 719d93cd5f5c (\"kvm/irqchip: Speed up KVM_SET_GSI_ROUTING\",\n2014-01-16).\n\nHowever, the docs are overly conservative.  You can have an SRCU instance\nonly has users in irq context, and you can mix process and irq context\nas long as process context users disable interrupts.  In addition,\n__srcu_read_unlock() actually uses this_cpu_dec() on both Tree SRCU and\nClassic SRCU.  For those two implementations, only srcu_read_lock()\nis unsafe.\n\nWhen Classic SRCU\u0027s __srcu_read_unlock() was changed to use this_cpu_dec(),\nin commit 5a41344a3d83 (\"srcu: Simplify __srcu_read_unlock() via\nthis_cpu_dec()\", 2012-11-29), __srcu_read_lock() did two increments.\nTherefore it kept __this_cpu_inc(), with preempt_disable/enable in\nthe caller.  Tree SRCU however only does one increment, so on most\narchitectures it is more efficient for __srcu_read_lock() to use\nthis_cpu_inc(), and any performance differences appear to be down in\nthe noise.\n\nCc: stable@vger.kernel.org\nFixes: 719d93cd5f5c (\"kvm/irqchip: Speed up KVM_SET_GSI_ROUTING\")\nReported-by: Linu Cherian \u003clinuc.decode@gmail.com\u003e\nSuggested-by: Linu Cherian \u003clinuc.decode@gmail.com\u003e\nCc: kvm@vger.kernel.org\nSigned-off-by: Paolo Bonzini \u003cpbonzini@redhat.com\u003e\nCc: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\nSigned-off-by: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\n[ paulmck: Backported to v4.9. ]\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "dc8eb63c6568a8b0d2b9a2d793f80f255f3fc570",
      "old_mode": 33188,
      "old_path": "include/linux/srcu.h",
      "new_id": "14b9bc1894e5b27abddb584591e07f9ccc17e7b8",
      "new_mode": 33188,
      "new_path": "include/linux/srcu.h"
    },
    {
      "type": "modify",
      "old_id": "9b9cdd549caa848111247b35b19109da7af9099d",
      "old_mode": 33188,
      "old_path": "kernel/rcu/srcu.c",
      "new_id": "a32b698e180c75e6c0a08b8341f6d6efeb789d37",
      "new_mode": 33188,
      "new_path": "kernel/rcu/srcu.c"
    }
  ]
}