1. 21 5月, 2017 1 次提交
    • M
      iio: trigger: fix NULL pointer dereference in iio_trigger_write_current() · 4eecbe81
      Marcin Niestroj 提交于
      In case oldtrig == trig == NULL (which happens when we set none
      trigger, when there is already none set) there is a NULL pointer
      dereference during iio_trigger_put(trig). Below is kernel output when
      this occurs:
      
      [   26.741790] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      [   26.750179] pgd = cacc0000
      [   26.752936] [00000000] *pgd=8adc6835, *pte=00000000, *ppte=00000000
      [   26.759531] Internal error: Oops: 17 [#1] SMP ARM
      [   26.764261] Modules linked in: usb_f_ncm u_ether usb_f_acm u_serial usb_f_fs libcomposite configfs evbug
      [   26.773844] CPU: 0 PID: 152 Comm: synchro Not tainted 4.12.0-rc1 #2
      [   26.780128] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
      [   26.786329] task: cb1de200 task.stack: cac92000
      [   26.790892] PC is at iio_trigger_write_current+0x188/0x1f4
      [   26.796403] LR is at lock_release+0xf8/0x20c
      [   26.800696] pc : [<c0736f34>]    lr : [<c016efb0>]    psr: 600d0013
      [   26.800696] sp : cac93e30  ip : cac93db0  fp : cac93e5c
      [   26.812193] r10: c0e64fe8  r9 : 00000000  r8 : 00000001
      [   26.817436] r7 : cb190810  r6 : 00000010  r5 : 00000001  r4 : 00000000
      [   26.823982] r3 : 00000000  r2 : 00000000  r1 : cb1de200  r0 : 00000000
      [   26.830528] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      [   26.837683] Control: 10c5387d  Table: 8acc006a  DAC: 00000051
      [   26.843448] Process synchro (pid: 152, stack limit = 0xcac92210)
      [   26.849475] Stack: (0xcac93e30 to 0xcac94000)
      [   26.853857] 3e20:                                     00000001 c0736dac c054033c cae6b680
      [   26.862060] 3e40: cae6b680 00000000 00000001 cb3f8610 cac93e74 cac93e60 c054035c c0736db8
      [   26.870264] 3e60: 00000001 c054033c cac93e94 cac93e78 c029bf34 c0540348 00000000 00000000
      [   26.878469] 3e80: cb3f8600 cae6b680 cac93ed4 cac93e98 c029b320 c029bef0 00000000 00000000
      [   26.886672] 3ea0: 00000000 cac93f78 cb2d41fc caed3280 c029b214 cac93f78 00000001 000e20f8
      [   26.894874] 3ec0: 00000001 00000000 cac93f44 cac93ed8 c0221dcc c029b220 c0e1ca39 cb2d41fc
      [   26.903079] 3ee0: cac93f04 cac93ef0 c0183ef0 c0183ab0 cb2d41fc 00000000 cac93f44 cac93f08
      [   26.911282] 3f00: c0225eec c0183ebc 00000001 00000000 c0223728 00000000 c0245454 00000001
      [   26.919485] 3f20: 00000001 caed3280 000e20f8 cac93f78 000e20f8 00000001 cac93f74 cac93f48
      [   26.927690] 3f40: c0223680 c0221da4 c0246520 c0245460 caed3283 caed3280 00000000 00000000
      [   26.935893] 3f60: 000e20f8 00000001 cac93fa4 cac93f78 c0224520 c02235e4 00000000 00000000
      [   26.944096] 3f80: 00000001 000e20f8 00000001 00000004 c0107f84 cac92000 00000000 cac93fa8
      [   26.952299] 3fa0: c0107de0 c02244e8 00000001 000e20f8 0000000e 000e20f8 00000001 fbad2484
      [   26.960502] 3fc0: 00000001 000e20f8 00000001 00000004 beb6b698 00064260 0006421c beb6b4b4
      [   26.968705] 3fe0: 00000000 beb6b450 b6f219a0 b6e2f268 800d0010 0000000e cac93ff4 cac93ffc
      [   26.976896] Backtrace:
      [   26.979388] [<c0736dac>] (iio_trigger_write_current) from [<c054035c>] (dev_attr_store+0x20/0x2c)
      [   26.988289]  r10:cb3f8610 r9:00000001 r8:00000000 r7:cae6b680 r6:cae6b680 r5:c054033c
      [   26.996138]  r4:c0736dac r3:00000001
      [   26.999747] [<c054033c>] (dev_attr_store) from [<c029bf34>] (sysfs_kf_write+0x50/0x54)
      [   27.007686]  r5:c054033c r4:00000001
      [   27.011290] [<c029bee4>] (sysfs_kf_write) from [<c029b320>] (kernfs_fop_write+0x10c/0x224)
      [   27.019579]  r7:cae6b680 r6:cb3f8600 r5:00000000 r4:00000000
      [   27.025271] [<c029b214>] (kernfs_fop_write) from [<c0221dcc>] (__vfs_write+0x34/0x120)
      [   27.033214]  r10:00000000 r9:00000001 r8:000e20f8 r7:00000001 r6:cac93f78 r5:c029b214
      [   27.041059]  r4:caed3280
      [   27.043622] [<c0221d98>] (__vfs_write) from [<c0223680>] (vfs_write+0xa8/0x170)
      [   27.050959]  r9:00000001 r8:000e20f8 r7:cac93f78 r6:000e20f8 r5:caed3280 r4:00000001
      [   27.058731] [<c02235d8>] (vfs_write) from [<c0224520>] (SyS_write+0x44/0x98)
      [   27.065806]  r9:00000001 r8:000e20f8 r7:00000000 r6:00000000 r5:caed3280 r4:caed3283
      [   27.073582] [<c02244dc>] (SyS_write) from [<c0107de0>] (ret_fast_syscall+0x0/0x1c)
      [   27.081179]  r9:cac92000 r8:c0107f84 r7:00000004 r6:00000001 r5:000e20f8 r4:00000001
      [   27.088947] Code: 1a000009 e1a04009 e3a06010 e1a05008 (e5943000)
      [   27.095244] ---[ end trace 06d1dab86d6e6bab ]---
      
      To fix that problem call iio_trigger_put(trig) only when trig is not
      NULL.
      
      Fixes: d5d24bcc ("iio: trigger: close race condition in acquiring trigger reference")
      Signed-off-by: NMarcin Niestroj <m.niestroj@grinn-global.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      4eecbe81
  2. 22 1月, 2017 3 次提交
  3. 28 9月, 2016 1 次提交
  4. 10 9月, 2016 1 次提交
    • L
      iio: trigger: helpers to determine own trigger · 702a7b8e
      Linus Walleij 提交于
      This adds a helper function to the IIO trigger framework:
      
      iio_trigger_using_own(): for an IIO device, this tells
        whether the device is using itself as a trigger.
        This is true if the indio device:
        (A) supplies a trigger and
        (B) has assigned its own buffer poll function to use this
            trigger.
      
      This helper function is good when constructing triggered,
      buffered drivers that can either use its own hardware *OR*
      an external trigger such as a HRTimer or even the trigger from
      a totally different sensor.
      
      Under such circumstances it is important to know for example
      if the timestamp from the same trigger hardware should be used
      when populating the buffer: if iio_trigger_using_own() is true,
      we can use this timestamp, else we need to pick a unique
      timestamp directly in the trigger handler.
      
      For this to work of course IIO devices registering hardware
      triggers must follow the convention to set the parent device
      properly, as as well as setting the parent of the IIO device
      itself.
      
      When a new poll function is attached, we check if the parent
      device of the IIO of the poll function is the same as the
      parent device of the trigger and in that case we conclude that
      the hardware is using itself as trigger.
      
      Cc: Giuseppe Barba <giuseppe.barba@st.com>
      Cc: Denis Ciocca <denis.ciocca@st.com>
      Cc: Crestez Dan Leonard <leonard.crestez@intel.com>
      Cc: Gregor Boirie <gregor.boirie@parrot.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      702a7b8e
  5. 04 9月, 2016 1 次提交
  6. 03 9月, 2016 1 次提交
  7. 01 7月, 2016 1 次提交
  8. 28 6月, 2016 1 次提交
  9. 03 6月, 2016 1 次提交
  10. 29 5月, 2016 1 次提交
  11. 28 8月, 2015 1 次提交
  12. 08 8月, 2015 1 次提交
  13. 14 6月, 2014 1 次提交
  14. 18 2月, 2014 1 次提交
  15. 04 12月, 2013 1 次提交
  16. 25 11月, 2013 3 次提交
  17. 18 8月, 2013 1 次提交
  18. 20 7月, 2013 1 次提交
    • L
      iio:trigger: Fix use_count race condition · a1a8e1dc
      Lars-Peter Clausen 提交于
      When using more than one trigger consumer it can happen that multiple threads
      perform a read-modify-update cycle on 'use_count' concurrently. This can cause
      updates to be lost and use_count can get stuck at non-zero value, in which case
      the IIO core assumes that at least one thread is still running and will wait for
      it to finish before running any trigger handlers again. This effectively renders
      the trigger disabled and a reboot is necessary before it can be used again. To
      fix this make use_count an atomic variable. Also set it to the number of
      consumers before starting the first consumer, otherwise it might happen that
      use_count drops to 0 even though not all consumers have been run yet.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Tested-by: NDenis Ciocca <denis.ciocca@st.com>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      a1a8e1dc
  19. 29 6月, 2013 1 次提交
  20. 07 2月, 2013 1 次提交
  21. 08 7月, 2012 1 次提交
  22. 07 7月, 2012 1 次提交
  23. 23 6月, 2012 1 次提交
  24. 15 5月, 2012 1 次提交
  25. 30 4月, 2012 1 次提交
    • L
      staging:iio: Streamline API function naming · 7cbb7537
      Lars-Peter Clausen 提交于
      Currently we use two different naming schemes in the IIO API, iio_verb_object
      and iio_object_verb. E.g iio_device_register and iio_allocate_device. This
      patches renames instances of the later to the former. The patch also renames allocate to
      alloc as this seems to be the preferred form throughout the kernel.
      
      In particular the following renames are performed by the patch:
      	iio_put_device -> iio_device_put
      	iio_allocate_device -> iio_device_alloc
      	iio_free_device -> iio_device_free
      	iio_get_trigger -> iio_trigger_get
      	iio_put_trigger -> iio_trigger_put
      	iio_allocate_trigger -> iio_trigger_alloc
      	iio_free_trigger -> iio_trigger_free
      
      The conversion was done with the following coccinelle patch with manual fixes to
      comments and documentation.
      
      <smpl>
      @@
      @@
      -iio_put_device
      +iio_device_put
      @@
      @@
      -iio_allocate_device
      +iio_device_alloc
      @@
      @@
      -iio_free_device
      +iio_device_free
      @@
      @@
      -iio_get_trigger
      +iio_trigger_get
      @@
      @@
      -iio_put_trigger
      +iio_trigger_put
      @@
      @@
      -iio_allocate_trigger
      +iio_trigger_alloc
      @@
      @@
      -iio_free_trigger
      +iio_trigger_free
      </smpl>
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Acked-by: NJonathan Cameron <jic23@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7cbb7537
  26. 26 4月, 2012 2 次提交
  27. 02 12月, 2011 1 次提交
  28. 27 11月, 2011 3 次提交
  29. 11 10月, 2011 1 次提交
  30. 27 9月, 2011 2 次提交
  31. 07 9月, 2011 2 次提交