lkml.org 
[lkml]   [2011]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [PATCH] gpio/gpio-sysfs: Try to export busy GPIO line leads to wrong GPIO line exporting
Denis Kuzmenko wrote at Saturday, November 12, 2011 6:31 PM:
> From: Denis Kuzmenko <linux@solonet.org.ua>
>
> Fix bug in gpio-sysfs interface (export of busy GPIO line leads to export of different GPIO line).
>
> Signed-off-by: Denis Kuzmenko <linux@solonet.org.ua>
> ---
>
> Patch is against 3.0.9
> When trying to export GPIO line 37(40) which is already exported/requested by kernel code we got GPIO
> line 3(4) exported.
> Looks like this is done because `export_store` function doesn't return the number of processed bytes
> and gets a part of previous buffer again.
> This fix works for me (Samsung s3c2440).
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index a971e3d..ccec497 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -633,7 +633,7 @@ static ssize_t export_store(struct class *class,
> done:
> if (status)
> pr_debug("%s: status %d\n", __func__, status);
> - return status ? : len;
> + return len;
> }

I assume that when the error occurs, status is negative. Is it some
special value like EINTR, EAGAIN? I'm surprised that the retried write
is smaller than the whole original buffer.

What's actually retrying the failed write? Is it user-space in response
to the previous failed write, in a (mistaken?) attempt to handle shorter-
than-expected-writes? You could confirm this with strace.

If the patch above really is correct, there are other places it'd be
needed; it looks like e.g. drivers/video/backlight/backlight.c would
have the same issue if you gave too-large integers to its sysfs files.

--
nvpublic



\
 
 \ /
  Last update: 2011-11-14 21:47    [W:0.052 / U:32.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site