bugfix: general: use GFP_ATOMIC for registration-time allocs

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 <rubini@gnudd.com>
Acked-by: Federico Vaga <federico.vaga@gmail.com>
chardev: fix locking bug introduced by an overlook in a90aba09

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 <rubini@gnudd.com>
Acked-by: Federico Vaga <federico.vaga@gmail.com>
bugfix in buffers: block might be used after being freed

[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 <rubini@gnudd.com>
Acked-by: Federico Vaga <federico.vaga@gmail.com>
bugfix: typo in flag management (no effect)

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 <rubini@gnudd.com>
Acked-by: Federico Vaga <federico.vaga@gmail.com>
bugfix: sysfs: change interaction of configuration and data I/O

When a process is writing and another process is changing the
configuration, it may happen that the trigger-related store calling
abort_disable() zeroes the active_block that is already being pushed
by the other process.

This fixes the interaction by keeping the cset spinlock during the whole
configuration of a sysfs attribute, thus preventing a write to sneak in.

After changing parameters, if the trigger was armed, the code re-arms
it, and this covers self-timed devices.  The choice helps simple tests
from the shell, but serious users will likely want to manually disable
the trigger before reconfiguring it.

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Acked-by: Federico Vaga <federico.vaga@gmail.com>
bugfix: prevent recursion in data_done/arm_trigger

Very fast self-timed input channels triggerd a recursion, with kernel
stack overflow: zio_arm_trigger was calling zio_trigger_data_done,
which in turn called zio_arm_trigger again.

We can't change the semantics of zio_trigger_data_done(), since that's
what most drivers call (they simply ignore the existence of
zio_arm_trigger, which is good).  So this commit introduces iteration
in zio_arm_trigger itself, relying on an internal version of
zio_trigger_data_done that doesn't call zio_arm_trigger.

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Acked-by: Federico Vaga <federico.vaga@gmail.com>
bugfix: read control always return 512 byte

Signed-off-by: Federico Vaga <federico.vaga@gmail.com>
Acked-by: Alessandro Rubini <rubini@gnudd.com>