Skip to content

Z
ZIO
Switch branch/tag
  1. 11 Jun, 2014 3 commits
  3. 25 Apr, 2014 3 commits
  5. 24 Apr, 2014 3 commits
    • Alessandro Rubini's avatar
      zio_trigger_abort_disable() may sleep, waiting for CSET_HW_BUSY · bd476cb4
      Alessandro Rubini authored 
      Previously, the enable/disable sysfs store had to complete atomically,
as zio takes a spinlock to serialize the various concurrent enable and
disable that may happen.

Unfortunately, this is a problem when the hardware is keeping data
structures busy, and commit b77ca7f0 is not enough to solve the
problem: That commit uses udelay(10) in a loop, but in one
installation of ours the hardware operation runs in a work queue,
whereas the driving application has real-time priority.  So we really
need to schedule (or change the priorities, which is denied to us).
But we cannot schedule while holding a spinlock.

This patch, thus, make the following changes:

* zio_trigger_abort_disable() is renamed to __zio_trigger_abort_disable()
and does not sleep, but it returns -EAGAIN if HW_BUSY.

* a new zio_trigger_abort_disable() is offered, that retries while
scheduling.  This covers all sysfs users, but one, so this keeps the
patch smaller than I initially wrote it.

* __zobj_enable() return int, not void: 0 or -EAGAIN (without
sleeping, as it calls the new __zio_trigger_abort_disable()). It's an
internal function in ./sysfs.c, so this is not a problem.

* zobj_store_enable() accepts -AGAIN, and loops over if so.

This is more difficult than expected (I loved b77ca7f0), but I see no
easier solution to the weird RT priorities our users deploy.
Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
Acked-by: 's avatarFederico Vaga <federico.vaga@gmail.com>
      bd476cb4
    • Alessandro Rubini's avatar
      cset: rename BUSY to HW_BUSY · 1298bc57
      Alessandro Rubini authored 
      This flag has one user no more, but I already found the name
confusing while working on that only user -- a driver.

So this renames the flag, to make clear to readers (and myself) that
only hardware can set and clear the flag, obviously under cset lock.
Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
Acked-by: 's avatarFederico Vaga <federico.vaga@gmail.com>
      1298bc57
    • Federico Vaga's avatar
      bus: use bus_groups instead of bus_attrs on kernel > 3.11 · faf2a79c
      Federico Vaga authored 
      The Linux kernel patch b4e46138f946442608647be58e78e3ad4d15534e
removes bus_type.bus_attrs
Signed-off-by: Federico Vaga's avatarFederico Vaga <federico.vaga@cern.ch>
Acked-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      faf2a79c
  7. 02 Apr, 2014 1 commit
  9. 07 Mar, 2014 4 commits
  11. 04 Mar, 2014 1 commit
  13. 26 Feb, 2014 3 commits
  15. 24 Feb, 2014 6 commits
  17. 30 Jan, 2014 3 commits
  19. 24 Jan, 2014 4 commits
    • Alessandro Rubini's avatar
      bugfix: typo in flag management (no effect) · 3f618ff9
      Alessandro Rubini authored 
      This typo was zeroing all unrelated flags in ti->falgs when
zio_trigger_abort_disable, but it had no effect at this point since
we have only one other flag, which is zeroed by this function anyways.
Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
Acked-by: 's avatarFederico Vaga <federico.vaga@gmail.com>
      3f618ff9
    • Alessandro Rubini's avatar
      bugfix in buffers: block might be used after being freed · a53f2c01
      Alessandro Rubini authored 
      [This commit originated in zio-v1.0-fixed, and I then adapted to
the current master]

With trigger user and output channels, a block may be referenced after
being released. This affects both kmalloc and vmalloc buffers.

This bug was introduced by commit 2300e624, partly reversed by this.
However, we only noticed when running under CONFIG_DEBUG_SLAB.

Bug description:

  When store_block is called for output the first time, it pushes to
  the trigger, but as of commit 2300e624 it adds the block to the
  list first (to keep ordering if another push happens very soon).
  If push succeeds *and* cset->raw_io succeeds immediately, the
  block is freed.  Store_block will thus remove it from the list
  of enqueued blocks, accessing the data structure.

Bug solution:

  The store_block method runs calls trigger->push in locked context,
  like it used to before 2300e624. Thus, the block doesn't need
  to be enqueued (as other store processes are waiting for the
  spinlock) and is not dequeued if push succeeds.

The ZIO_BI_PUSHING flag remains, to prevent the deadlock when
store succeeds and data_done() tries to retrieve the next block.
However, it is checked by retr_block before taking the lock.

Update for master branch: the commit also removes the locking in
the new helpers zio_buffer_retr_block() and zio_buffer_store_block(),
because the functions are now called in locking context; suck a lock
is not needed anyways, because the critical section is just reading the
DISABLED flag, which is atomic by definition.
Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
Acked-by: 's avatarFederico Vaga <federico.vaga@gmail.com>
      a53f2c01
    • Alessandro Rubini's avatar
      chardev: fix locking bug introduced by an overlook in a90aba09 · 98c46fd6
      Alessandro Rubini authored 
      this commit
   a90aba09  chardev: return POLLERR if user disables the trigger

removed in error the mutex_unlock() from zio_can_w_ctrl(). This
results in an immediate deadlock when anybody writes a control
structure.  The fix is trivial.
Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
Acked-by: 's avatarFederico Vaga <federico.vaga@gmail.com>
      98c46fd6
    • Alessandro Rubini's avatar
      bugfix: general: use GFP_ATOMIC for registration-time allocs · ea64d1f0
      Alessandro Rubini authored 
      Registration of devices is done with a mutex held. as device_attach()
calls device_lock() (in the upstream kernel).

Thus, allocation of minor numbers must use GFP_ATOMIC. Similarly, the
default buffer and the default trigger for a new device being
registered are allocated within the critical section.

The problem also applies when changing a buffer or trigger type
at runtime, because sysfs_write_file() takes a mutex on the file.
Thus, all triggers and buffers are affected.
Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
Acked-by: 's avatarFederico Vaga <federico.vaga@gmail.com>
      ea64d1f0
  21. 22 Jan, 2014 3 commits
  23. 20 Jan, 2014 2 commits
  25. 18 Jan, 2014 4 commits