From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Colin Cross <ccross@android.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>,
Greg KH <gregkh@linuxfoundation.org>,
lkml <linux-kernel@vger.kernel.org>,
Bryan Wu <bryan.wu@canonical.com>
Subject: Re: sysfs permissions on dynamic attributes (led delay_on and delay_off)
Date: Sat, 21 Jul 2012 13:08:55 -0300 [thread overview]
Message-ID: <20120721160855.GB7565@khazad-dum.debian.net> (raw)
In-Reply-To: <CAMbhsRQ2EPEW+=0bhE6N9-dr44H8G_gzQ7h5LqOp7Lntr2RhTg@mail.gmail.com>
On Sat, 21 Jul 2012, Colin Cross wrote:
> The delay_on and delay_off files could easily override the values from
> the trigger.
>
> Sending a KOBJ_CHANGE uevent is not a great solution, it's still
> horribly racy in userspace. This script would never work reliably:
> echo timer > trigger
> echo 1000 > delay_on
> echo 1000 > delay_off
> echo 255 > brightness
Yes, and the proper fix is to instead use a fully async userspace based on
uevent callbacks. Nasty as all hell. Or the quick fix, which is to wait
for the system to settle after every sysfs operation that could create new
sysfs nodes.
You could make sure that (1) no sysfs operation will return control to
userspace until it is complete, so you'd have all new sysfs nodes available
at the time the first echo returns [I believe it already works like that],
and (2) either enhance sysfs to create nodes with the desired ownership and
permissions -- which requires feeding policy rules to it beforehand at the
very least; or do it as whichever priviledged user/group has default write
access to sysfs nodes.
This is a general problem. I have no idea whether Richard will allow the
triggers hack to work around it or not, and I really don't care. But the
bad sideffects of the hack that he pointed out are all very true, and far
reaching in time.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
next prev parent reply other threads:[~2012-07-21 16:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-21 0:46 sysfs permissions on dynamic attributes (led delay_on and delay_off) Colin Cross
2012-07-21 4:08 ` Greg KH
2012-07-21 5:14 ` Colin Cross
2012-07-21 15:07 ` Greg KH
2012-07-21 7:33 ` Richard Purdie
2012-07-21 8:26 ` Colin Cross
2012-07-21 11:21 ` Richard Purdie
2012-07-21 14:31 ` Henrique de Moraes Holschuh
2012-07-21 15:42 ` Colin Cross
2012-07-21 16:08 ` Henrique de Moraes Holschuh [this message]
2012-07-21 16:15 ` Greg KH
2012-07-21 16:23 ` Colin Cross
2012-07-21 16:13 ` Greg KH
2012-07-21 16:22 ` Colin Cross
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=20120721160855.GB7565@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=bryan.wu@canonical.com \
--cc=ccross@android.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=richard.purdie@linuxfoundation.org \
/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;
as well as URLs for NNTP newsgroup(s).