Re: [PATCH] hidraw: fix list->buffer race condition
From: Jiri Kosina <jikos@kernel.org>
Date: 2016-10-07 08:44:49
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.
quoted hunk ↗ jump to hunk
--- 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?
quoted hunk ↗ jump to hunk
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.
quoted hunk ↗ jump to hunk
} 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?
quoted hunk ↗ jump to hunk
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