Skip to content
  1. Aug 27, 2016
  2. Aug 26, 2016
  3. Aug 23, 2016
  4. Aug 22, 2016
  5. Aug 09, 2016
  6. Aug 04, 2016
  7. Aug 03, 2016
  8. Aug 02, 2016
  9. Jul 31, 2016
    • Grygorii Strashko's avatar
      ARM: OMAP2+: omap_device: fix crash on omap_device removal · 213fa10d
      Grygorii Strashko authored
      
      
      Below call chain causes system crash when OMAP device is
      removed by calling of_platform_depopulate()/device_del():
      
      device_del()
      - blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
       			     BUS_NOTIFY_DEL_DEVICE, dev);
        - _omap_device_notifier_call()
          - omap_device_delete()
            - od->pdev->archdata.od = NULL;
      	kfree(od->hwmods);
      	kfree(od);
        - bus_remove_device()
          - device_release_driver()
            - __device_release_driver()
      	- pm_runtime_get_sync()
      	   - _od_runtime_resume()
      	     - omap_hwmod_enable() <- OOPS od's delted already
      
      Backtrace:
      Unable to handle kernel NULL pointer dereference at virtual address 0000000d
      pgd = eb100000
      [0000000d] *pgd=ad6e1831, *pte=00000000, *ppte=00000000
      Internal error: Oops: 17 [#1] PREEMPT SMP ARM
      CPU: 1 PID: 1273 Comm: modprobe Not tainted 4.4.15-rt19-00115-ge4d3cd3-dirty #68
      Hardware name: Generic DRA74X (Flattened Device Tree)
      task: eb1ee800 ti: ec962000 task.ti: ec962000
      PC is at omap_device_enable+0x10/0x90
      LR is at _od_runtime_resume+0x10/0x24
      [...]
      [<c00299dc>] (omap_device_enable) from [<c0029a6c>] (_od_runtime_resume+0x10/0x24)
      [<c0029a6c>] (_od_runtime_resume) from [<c04ad404>] (__rpm_callback+0x20/0x34)
      [<c04ad404>] (__rpm_callback) from [<c04ad438>] (rpm_callback+0x20/0x80)
      [<c04ad438>] (rpm_callback) from [<c04aee28>] (rpm_resume+0x48c/0x964)
      [<c04aee28>] (rpm_resume) from [<c04af360>] (__pm_runtime_resume+0x60/0x88)
      [<c04af360>] (__pm_runtime_resume) from [<c04a4974>] (__device_release_driver+0x30/0x100)
      [<c04a4974>] (__device_release_driver) from [<c04a4a60>] (device_release_driver+0x1c/0x28)
      [<c04a4a60>] (device_release_driver) from [<c04a38c0>] (bus_remove_device+0xec/0x144)
      [<c04a38c0>] (bus_remove_device) from [<c04a0764>] (device_del+0x10c/0x210)
      [<c04a0764>] (device_del) from [<c04a67b0>] (platform_device_del+0x18/0x84)
      [<c04a67b0>] (platform_device_del) from [<c04a6828>] (platform_device_unregister+0xc/0x20)
      [<c04a6828>] (platform_device_unregister) from [<c05adcfc>] (of_platform_device_destroy+0x8c/0x90)
      [<c05adcfc>] (of_platform_device_destroy) from [<c04a02f0>] (device_for_each_child+0x4c/0x78)
      [<c04a02f0>] (device_for_each_child) from [<c05adc5c>] (of_platform_depopulate+0x30/0x44)
      [<c05adc5c>] (of_platform_depopulate) from [<bf123920>] (cpsw_remove+0x68/0xf4 [ti_cpsw])
      [<bf123920>] (cpsw_remove [ti_cpsw]) from [<c04a68d8>] (platform_drv_remove+0x24/0x3c)
      [<c04a68d8>] (platform_drv_remove) from [<c04a49c8>] (__device_release_driver+0x84/0x100)
      [<c04a49c8>] (__device_release_driver) from [<c04a4b20>] (driver_detach+0xac/0xb0)
      [<c04a4b20>] (driver_detach) from [<c04a3be8>] (bus_remove_driver+0x60/0xd4)
      [<c04a3be8>] (bus_remove_driver) from [<c00d9870>] (SyS_delete_module+0x184/0x20c)
      [<c00d9870>] (SyS_delete_module) from [<c0010540>] (ret_fast_syscall+0x0/0x1c)
      Code: e3500000 e92d4070 1590630c 01a06000 (e5d6300d)
      
      Hence, fix it by using BUS_NOTIFY_REMOVED_DEVICE event for OMAP device
      deletion which is sent when DD has finished processing of device
      deletion.
      
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      213fa10d
  10. Jul 27, 2016
  11. Jul 25, 2016
    • Vitaly Kuznetsov's avatar
      x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op · ad5475f9
      Vitaly Kuznetsov authored
      
      
      HYPERVISOR_vcpu_op() passes Linux's idea of vCPU id as a parameter
      while Xen's idea is expected. In some cases these ideas diverge so we
      need to do remapping.
      
      Convert all callers of HYPERVISOR_vcpu_op() to use xen_vcpu_nr().
      
      Leave xen_fill_possible_map() and xen_filter_cpu_maps() intact as
      they're only being called by PV guests before perpu areas are
      initialized. While the issue could be solved by switching to
      early_percpu for xen_vcpu_id I think it's not worth it: PV guests will
      probably never get to the point where their idea of vCPU id diverges
      from Xen's.
      
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      ad5475f9