This series is a follow up to my recent kfifo initialisation fix[1].
Patch 1 adds calling INIT_KFIFO() on the event kfifo in order to induce
an oops if the kfifo is accessed prior to being allocated. Not calling
INIT_KFIFO() could be considered an abuse of the kfifo API. I don't
recall, but it is possible that it was not being called as we also make
use of kfifo_initialized(), and the assumption was that it would return
true after the INIT_KFIFO() call. In fact it only returns true once
the kfifo has been allocated.
Patch 2 adds a helper to perform the allocation of the kfifo to reduce
code duplication.
Patch 3 tidies up the handling of kfifo_out() errors, making them
visible where they may currently be obscured. These errors are not
expected to ever happen, so this should not produce any visible
difference, but if they do occur it will now be more obvious.
Cheers,
Kent.
Changes v1 -> v2:
- add WARN() to patch 3.
Kent Gibson (3):
gpiolib: cdev: Add INIT_KFIFO() for linereq events
gpiolib: cdev: Refactor allocation of linereq events kfifo
gpiolib: cdev: Cleanup kfifo_out() error handling
drivers/gpio/gpiolib-cdev.c | 80 +++++++++++++++++++------------------
1 file changed, 41 insertions(+), 39 deletions(-)
--
2.39.2
The initialisation of the linereq events kfifo relies on the struct being
zeroed and a subsequent call to kfifo_alloc(). The call to kfifo_alloc()
is deferred until edge detection is first enabled for the linereq. If the
kfifo is inadvertently accessed before the call to kfifo_alloc(), as was
the case in a recently discovered bug, it behaves as a FIFO of size 1 with
an element size of 0, so writes and reads to the kfifo appear successful
but copy no actual data.
As a defensive measure, initialise the kfifo with INIT_KFIFO() when the
events kfifo is constructed. This initialises the kfifo element size
and zeroes its data pointer, so any inadvertant access prior to the
kfifo_alloc() call will trigger an oops.
Signed-off-by: Kent Gibson <[email protected]>
---
drivers/gpio/gpiolib-cdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index 9dad67ea2597..d4e47960cc98 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -1774,6 +1774,7 @@ static int linereq_create(struct gpio_device *gdev, void __user *ip)
mutex_init(&lr->config_mutex);
init_waitqueue_head(&lr->wait);
+ INIT_KFIFO(lr->events);
lr->event_buffer_size = ulr.event_buffer_size;
if (lr->event_buffer_size == 0)
lr->event_buffer_size = ulr.num_lines * 16;
--
2.39.2
The handling of kfifo_out() errors in read functions obscures any error.
The error condition should never occur but, while a ret is set to -EIO, it
is subsequently ignored and the read functions instead return the number
of bytes copied to that point, potentially masking the fact that any error
occurred.
Log a warning and return -EIO in the case of a kfifo_out() error to make
it clear something very odd is going on here.
Signed-off-by: Kent Gibson <[email protected]>
---
drivers/gpio/gpiolib-cdev.c | 53 +++++++++++++++++++------------------
1 file changed, 27 insertions(+), 26 deletions(-)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index c7218c9f2c5e..1cb952daacfb 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -1642,16 +1642,15 @@ static ssize_t linereq_read(struct file *file, char __user *buf,
return ret;
}
- ret = kfifo_out(&lr->events, &le, 1);
- }
- if (ret != 1) {
- /*
- * This should never happen - we were holding the
- * lock from the moment we learned the fifo is no
- * longer empty until now.
- */
- ret = -EIO;
- break;
+ if (kfifo_out(&lr->events, &le, 1) != 1) {
+ /*
+ * This should never happen - we hold the
+ * lock from the moment we learned the fifo
+ * is no longer empty until now.
+ */
+ WARN(1, "failed to read from non-empty kfifo");
+ return -EIO;
+ }
}
if (copy_to_user(buf + bytes_read, &le, sizeof(le)))
@@ -1995,16 +1994,15 @@ static ssize_t lineevent_read(struct file *file, char __user *buf,
return ret;
}
- ret = kfifo_out(&le->events, &ge, 1);
- }
- if (ret != 1) {
- /*
- * This should never happen - we were holding the lock
- * from the moment we learned the fifo is no longer
- * empty until now.
- */
- ret = -EIO;
- break;
+ if (kfifo_out(&le->events, &ge, 1) != 1) {
+ /*
+ * This should never happen - we hold the
+ * lock from the moment we learned the fifo
+ * is no longer empty until now.
+ */
+ WARN(1, "failed to read from non-empty kfifo");
+ return -EIO;
+ }
}
if (copy_to_user(buf + bytes_read, &ge, ge_size))
@@ -2707,12 +2705,15 @@ static ssize_t lineinfo_watch_read(struct file *file, char __user *buf,
if (count < event_size)
return -EINVAL;
#endif
- ret = kfifo_out(&cdev->events, &event, 1);
- }
- if (ret != 1) {
- ret = -EIO;
- break;
- /* We should never get here. See lineevent_read(). */
+ if (kfifo_out(&cdev->events, &event, 1) != 1) {
+ /*
+ * This should never happen - we hold the
+ * lock from the moment we learned the fifo
+ * is no longer empty until now.
+ */
+ WARN(1, "failed to read from non-empty kfifo");
+ return -EIO;
+ }
}
#ifdef CONFIG_GPIO_CDEV_V1
--
2.39.2
The allocation of the linereq events kfifo is performed in two separate
places. Add a helper function to remove the duplication.
Signed-off-by: Kent Gibson <[email protected]>
---
drivers/gpio/gpiolib-cdev.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
index d4e47960cc98..c7218c9f2c5e 100644
--- a/drivers/gpio/gpiolib-cdev.c
+++ b/drivers/gpio/gpiolib-cdev.c
@@ -1128,6 +1128,14 @@ static void edge_detector_stop(struct line *line)
/* do not change line->level - see comment in debounced_value() */
}
+static int edge_detector_fifo_init(struct linereq *req)
+{
+ if (kfifo_initialized(&req->events))
+ return 0;
+
+ return kfifo_alloc(&req->events, req->event_buffer_size, GFP_KERNEL);
+}
+
static int edge_detector_setup(struct line *line,
struct gpio_v2_line_config *lc,
unsigned int line_idx, u64 edflags)
@@ -1139,9 +1147,8 @@ static int edge_detector_setup(struct line *line,
char *label;
eflags = edflags & GPIO_V2_LINE_EDGE_FLAGS;
- if (eflags && !kfifo_initialized(&line->req->events)) {
- ret = kfifo_alloc(&line->req->events,
- line->req->event_buffer_size, GFP_KERNEL);
+ if (eflags) {
+ ret = edge_detector_fifo_init(line->req);
if (ret)
return ret;
}
@@ -1193,8 +1200,6 @@ static int edge_detector_update(struct line *line,
struct gpio_v2_line_config *lc,
unsigned int line_idx, u64 edflags)
{
- u64 eflags;
- int ret;
u64 active_edflags = READ_ONCE(line->edflags);
unsigned int debounce_period_us =
gpio_v2_line_config_debounce_period(lc, line_idx);
@@ -1210,14 +1215,9 @@ static int edge_detector_update(struct line *line,
* ensure event fifo is initialised if edge detection
* is now enabled.
*/
- eflags = edflags & GPIO_V2_LINE_EDGE_FLAGS;
- if (eflags && !kfifo_initialized(&line->req->events)) {
- ret = kfifo_alloc(&line->req->events,
- line->req->event_buffer_size,
- GFP_KERNEL);
- if (ret)
- return ret;
- }
+ if (edflags & GPIO_V2_LINE_EDGE_FLAGS)
+ return edge_detector_fifo_init(line->req);
+
return 0;
}
--
2.39.2
From: Bartosz Golaszewski <[email protected]>
On Wed, 29 May 2024 21:19:50 +0800, Kent Gibson wrote:
> This series is a follow up to my recent kfifo initialisation fix[1].
>
> Patch 1 adds calling INIT_KFIFO() on the event kfifo in order to induce
> an oops if the kfifo is accessed prior to being allocated. Not calling
> INIT_KFIFO() could be considered an abuse of the kfifo API. I don't
> recall, but it is possible that it was not being called as we also make
> use of kfifo_initialized(), and the assumption was that it would return
> true after the INIT_KFIFO() call. In fact it only returns true once
> the kfifo has been allocated.
>
> [...]
Applied, thanks!
[1/3] gpiolib: cdev: Add INIT_KFIFO() for linereq events
commit: 35d848e7a1cbba2649ed98cf58e0cdc7ee560c7a
[2/3] gpiolib: cdev: Refactor allocation of linereq events kfifo
commit: 4ce5ca654a761462a222164e96b8ab953b8cacab
[3/3] gpiolib: cdev: Cleanup kfifo_out() error handling
commit: 2ba4746b418dcffadb3b135657fea8d3e62b4c30
Best regards,
--
Bartosz Golaszewski <[email protected]>