On Tue, 4 Oct 2016, Gary King wrote:
> hidraw input events are stored for each file descriptor in a lockless
> circular queue.
Well, there is a per-hidraw device list_lock; but you're right that it's
usage throughout hidraw.c is probably incomplete and that should be fixed.
> ---
> drivers/hid/hidraw.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
> index f0e2757..dc3465f 100644
> --- a/drivers/hid/hidraw.c
> +++ b/drivers/hid/hidraw.c
> @@ -53,6 +53,7 @@ static ssize_t hidraw_read(struct file *file, char __user *buffer, size_t count,
> mutex_lock(&list->read_mutex);
>
> while (ret == 0) {
> + smp_rmb();
Which _wmb() does this one pair with?
> if (list->head == list->tail) {
> add_wait_queue(&list->hidraw->wait, &wait);
> set_current_state(TASK_INTERRUPTIBLE);
> @@ -98,7 +99,9 @@ static ssize_t hidraw_read(struct file *file, char __user *buffer, size_t count,
>
> kfree(list->buffer[list->tail].value);
> list->buffer[list->tail].value = NULL;
> + smp_wmb();
> list->tail = (list->tail + 1) & (HIDRAW_BUFFER_SIZE - 1);
> + smp_wmb();
This is completely confusing; it seems like you imply that those two
_wmb() should pair together, but that makes no sense. Please always, when
using SMP barriers, document which _rmb() pairs to which _wmb(), otherwise
the rules become quickly totally unclear.
> }
> out:
> mutex_unlock(&list->read_mutex);
> @@ -487,7 +490,7 @@ int hidraw_report_event(struct hid_device *hid, u8 *data, int len)
> spin_lock_irqsave(&dev->list_lock, flags);
> list_for_each_entry(list, &dev->list, node) {
> int new_head = (list->head + 1) & (HIDRAW_BUFFER_SIZE - 1);
> -
> + smp_rmb();
> if (new_head == list->tail)
Again, which _wmb() does this one pair with please?
> continue;
>
> @@ -496,7 +499,9 @@ int hidraw_report_event(struct hid_device *hid, u8 *data, int len)
> break;
> }
> list->buffer[list->head].len = len;
> + smp_wmb();
> list->head = new_head;
> + smp_wmb();
Same as in hidraw_read(), I completely fail to see the point of having two
here. Which read side does each of those pair with?
I think this is just papering the real problem (missing list_lock) over in
an odd way; could you please look into whether locking list_lock properly
would resolve the crashes you're able to trigger on your ARM system?
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
