I've updated this patch following your remarks about PATCH 1/3.

About your feedback, I am not sure I understand what you mean, but I will try:

  > Do not release the lock before the ringbuffer is consistent again.

If you mean that the lock should not be released while buf->data = NULL, this is *not* a problem.
A ringbuffer with NULL data *is* consistent (even though it is useless).
All functions in dmxdev.c check for a NULL pointer before calling read or write on the ringbuffer.
The same happens for the buffer of the demux.

  > We should not free the old buffer before we got a new one.

I like you idea, but I did not want to change the existing logic.

You might have noticed that the new function dvb_dvr_set_buffer_size is very similar to
dvb_dmxdev_set_buffer_size (which exists already): I did not want to introduce a new logic of
resizing the ringbuffer, but I've written a function very very similar.

Maybe in a following patch one could change both of them.

  > As the ring buffer can be written from an ISR, we have to use
    spin_lock_irqsave/spin_unlock_irqrestore here.

Ok, I've changed the patch.
If I use spin_lock_irqsave in dvb_dvr_set_buffer_size (called via IOCTL), do I need to use the same
kind of spin_lock on all other spin_lock on the same lock (e.g. dvb_dmxdev_ts_callback)?




Let me know if I should be more aggressive and change the resize for dvr and demux at once within
this patch. Otherwise if and when this is accepted I will rearrange the code.

Andrea