From: Pavel Machek <pavel@ucw.cz>
To: Jacek Anaszewski <j.anaszewski@samsung.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCH] leds: Add mutex protection in brightness_show()
Date: Wed, 9 Nov 2016 21:26:26 +0100 [thread overview]
Message-ID: <20161109202625.GA9627@amd> (raw)
In-Reply-To: <20161109123751.GA3488@amd>
[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]
Hi!
> > Thanks for the analysis. Either way, this patch, with the modification
> > I mentioned in my previous message is required to assure proper
> > LED sysfs locking.
> >
> > Regarding the races between user and atomic context, I think that
> > it should be system root's responsibility to define LED access
> > policy. If a LED is registered for any trigger events then setting
> > brightness from user space should be made impossible. Such a hint
> > could be even added to the Documentation/leds/leds-class.txt.
>
> No, kernel locking may not depend on "root did not do anything
> stupid". Sorry.
>
> Is there problem with led_access becoming a spinlock, and
> brightness_set_blocking taking it internally while it reads the
> brightness (but not while sleeping)?
led_timer_function() does not seem to have any locking. IMO it needs
some, as it does not use atomic accesses.
Do we need a spinlock protecting led_classdev.flags and
delayed_set_value?
Would it be good idea to create new "blink_cancel" so brightness_set
is used just for .. brightness and not for timer manipulations?
Should we do something like this for consistency?
BTW how is locking expected to work with userland LED drivers? What if
userland LED driver accesses /sys files for its own LED? I'd really
prefer that patch not to be merged until we get locking right.
Thanks,
Pavel
diff --git a/include/linux/leds.h b/include/linux/leds.h
index ddfcb2d..60e436d 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -88,11 +88,11 @@ struct led_classdev {
unsigned long blink_delay_on, blink_delay_off;
struct timer_list blink_timer;
- int blink_brightness;
+ enum led_brightness blink_brightness;
void (*flash_resume)(struct led_classdev *led_cdev);
struct work_struct set_brightness_work;
- int delayed_set_value;
+ enum led_brightness delayed_set_value;
#ifdef CONFIG_LEDS_TRIGGERS
/* Protects the trigger data below */
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2016-11-09 20:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 7:52 [PATCH] leds: Add mutex protection in brightness_show() Jacek Anaszewski
2016-11-04 11:53 ` Hans de Goede
2016-11-04 16:06 ` Jacek Anaszewski
2016-11-04 16:46 ` Hans de Goede
2016-11-06 14:52 ` Hans de Goede
2016-11-07 9:11 ` Jacek Anaszewski
2016-11-09 12:37 ` Pavel Machek
2016-11-09 20:26 ` Pavel Machek [this message]
2016-11-09 21:23 ` Jacek Anaszewski
2016-11-09 12:38 ` Pavel Machek
2016-11-09 21:23 ` Jacek Anaszewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161109202625.GA9627@amd \
--to=pavel@ucw.cz \
--cc=andrew@lunn.ch \
--cc=hdegoede@redhat.com \
--cc=j.anaszewski@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox