linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Akinobu Mita <akinobu.mita@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-leds@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>, Dan Murphy <dmurphy@ti.com>
Subject: Re: [PATCH v2 1/1] leds: remove PAGE_SIZE limit of /sys/class/leds/<led>/trigger
Date: Sat, 28 Sep 2019 13:08:11 +0900	[thread overview]
Message-ID: <CAC5umyjZHtFnqrBujCEnBqAfYfsGHth6OnESyDFFdvtgEpZaDQ@mail.gmail.com> (raw)
In-Reply-To: <20190927174633.GB1802011@kroah.com>

2019年9月28日(土) 2:46 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
>
> On Sat, Sep 28, 2019 at 01:47:21AM +0900, Akinobu Mita wrote:
> > 2019年9月27日(金) 15:39 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> > >
> > > On Sat, Sep 14, 2019 at 12:03:24AM +0900, Akinobu Mita wrote:
> > > > Reading /sys/class/leds/<led>/trigger returns all available LED triggers.
> > > > However, the size of this file is limited to PAGE_SIZE because of the
> > > > limitation for sysfs attribute.
> > > >
> > > > Enabling LED CPU trigger on systems with thousands of CPUs easily hits
> > > > PAGE_SIZE limit, and makes it impossible to see all available LED triggers
> > > > and which trigger is currently activated.
> > > >
> > > > We work around it here by converting /sys/class/leds/<led>/trigger to
> > > > binary attribute, which is not limited by length. This is _not_ good
> > > > design, do not copy it.
> > > >
> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> > > > Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> > > > Cc: Pavel Machek <pavel@ucw.cz>
> > > > Cc: Dan Murphy <dmurphy@ti.com>
> > > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > > Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> > > > ---
> > > >  drivers/leds/led-class.c    |  8 ++--
> > > >  drivers/leds/led-triggers.c | 90 ++++++++++++++++++++++++++++++++++-----------
> > > >  drivers/leds/leds.h         |  6 +++
> > > >  include/linux/leds.h        |  5 ---
> > > >  4 files changed, 79 insertions(+), 30 deletions(-)
> > > >
> > > > diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> > > > index 4793e77..8b5a1d1 100644
> > > > --- a/drivers/leds/led-class.c
> > > > +++ b/drivers/leds/led-class.c
> > > > @@ -73,13 +73,13 @@ static ssize_t max_brightness_show(struct device *dev,
> > > >  static DEVICE_ATTR_RO(max_brightness);
> > > >
> > > >  #ifdef CONFIG_LEDS_TRIGGERS
> > > > -static DEVICE_ATTR(trigger, 0644, led_trigger_show, led_trigger_store);
> > > > -static struct attribute *led_trigger_attrs[] = {
> > > > -     &dev_attr_trigger.attr,
> > > > +static BIN_ATTR(trigger, 0644, led_trigger_read, led_trigger_write, 0);
> > > > +static struct bin_attribute *led_trigger_bin_attrs[] = {
> > > > +     &bin_attr_trigger,
> > > >       NULL,
> > > >  };
> > > >  static const struct attribute_group led_trigger_group = {
> > > > -     .attrs = led_trigger_attrs,
> > > > +     .bin_attrs = led_trigger_bin_attrs,
> > > >  };
> > > >  #endif
> > > >
> > > > diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
> > > > index 8d11a5e..ed5a311 100644
> > > > --- a/drivers/leds/led-triggers.c
> > > > +++ b/drivers/leds/led-triggers.c
> > > > @@ -16,6 +16,7 @@
> > > >  #include <linux/rwsem.h>
> > > >  #include <linux/leds.h>
> > > >  #include <linux/slab.h>
> > > > +#include <linux/mm.h>
> > > >  #include "leds.h"
> > > >
> > > >  /*
> > > > @@ -26,9 +27,11 @@ LIST_HEAD(trigger_list);
> > > >
> > > >   /* Used by LED Class */
> > > >
> > > > -ssize_t led_trigger_store(struct device *dev, struct device_attribute *attr,
> > > > -             const char *buf, size_t count)
> > > > +ssize_t led_trigger_write(struct file *filp, struct kobject *kobj,
> > > > +                       struct bin_attribute *bin_attr, char *buf,
> > > > +                       loff_t pos, size_t count)
> > > >  {
> > > > +     struct device *dev = kobj_to_dev(kobj);
> > > >       struct led_classdev *led_cdev = dev_get_drvdata(dev);
> > > >       struct led_trigger *trig;
> > > >       int ret = count;
> > > > @@ -64,39 +67,84 @@ ssize_t led_trigger_store(struct device *dev, struct device_attribute *attr,
> > > >       mutex_unlock(&led_cdev->led_access);
> > > >       return ret;
> > > >  }
> > > > -EXPORT_SYMBOL_GPL(led_trigger_store);
> > > > +EXPORT_SYMBOL_GPL(led_trigger_write);
> > > >
> > > > -ssize_t led_trigger_show(struct device *dev, struct device_attribute *attr,
> > > > -             char *buf)
> > > > +__printf(4, 5)
> > > > +static int led_trigger_snprintf(char *buf, size_t size, bool query,
> > > > +                             const char *fmt, ...)
> > > > +{
> > > > +     va_list args;
> > > > +     int i;
> > > > +
> > > > +     va_start(args, fmt);
> > > > +     if (query)
> > > > +             i = vsnprintf(NULL, 0, fmt, args);
> > > > +     else
> > > > +             i = vscnprintf(buf, size, fmt, args);
> > > > +     va_end(args);
> > > > +
> > > > +     return i;
> > > > +}
> > >
> > > You only call this in one place, why is it needed like this?  The "old"
> > > code open-coded this, what is this helping with here?
> > >
> > > And what does "query" mean here?  I have no idea how that variable
> > > matters, or what it does.  Why not just test if buf is NULL or not if
> > > you don't want to use it?
> > >
> > > Ah, you are trying to see how "long" the buffer is going to be.  That
> > > makes more sense, but just trigger off of the NULL buffer or not, making
> > > this a bit more "obvious" what you are doing and not tieing two
> > > parameters to each other (meaning one always reflects the other one).
> >
> > We cannot simply replace the "query" by checking the buffer is NULL or not.
> > Because led_trigger_snprintf() is repeatedly called by led_trigger_format()
> > while increasing 'buf' and decreasing 'size' by the return value of
> > led_trigger_snprintf() every time.
>
> Odd, but ok, I'll trust you, this looks like very odd code :(

We can remove the "query" by checking if "size" is less than or equal to
zero in led_trigger_snprintf(), instead of checking "buf".

Because the "size" keeps decreasing every time led_trigger_snprintf() is
called by led_trigger_format().

      reply	other threads:[~2019-09-28  4:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-13 15:03 [PATCH v2 0/1] leds: fix /sys/class/leds/<led>/trigger Akinobu Mita
2019-09-13 15:03 ` [PATCH v2 1/1] leds: remove PAGE_SIZE limit of /sys/class/leds/<led>/trigger Akinobu Mita
2019-09-24 21:30   ` Jacek Anaszewski
2019-09-27  6:27     ` Greg Kroah-Hartman
2019-09-27  6:35   ` Greg Kroah-Hartman
2019-09-27 16:47     ` Akinobu Mita
2019-09-27 16:59       ` Pavel Machek
2019-09-27 17:46       ` Greg Kroah-Hartman
2019-09-28  4:08         ` Akinobu Mita [this message]

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=CAC5umyjZHtFnqrBujCEnBqAfYfsGHth6OnESyDFFdvtgEpZaDQ@mail.gmail.com \
    --to=akinobu.mita@gmail.com \
    --cc=dmurphy@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rafael@kernel.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).