linux-kernel - Re: kernfs: can read/write method grow buffer size?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190329103835.GB23356@atrey.karlin.mff.cuni.cz>
Date:   Fri, 29 Mar 2019 11:38:35 +0100
From:   Pavel Machek <pavel@....cz>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Marek Behun <marek.behun@....cz>, Tejun Heo <tj@...nel.org>,
        linux-kernel@...r.kernel.org,
        Jacek Anaszewski <jacek.anaszewski@...il.com>
Subject: Re: kernfs: can read/write method grow buffer size?

Hi!

> > > Yes, and cpufreq governors too list available governosrs as space
> > > separated list.
> > > Maybe the "one value per file" rule was thought-of only after these
> > > were merged?
> > 
> > For small numbers of things, like /sys/power/state, which was the first
> > file to use this style, it was fine as we "knew" this was going to be a
> > small, well-bounded list of states that the file could be in.
> > 
> > As you have seen, 'trigger' is not that, and I am pretty sure I have
> > complained about this in the past.
> > 
> > I suggest you use a different way of "discovering" what types of
> > triggers are available.  I don't know what would work best for you, but
> > any time you are ever worried about the size of a sysfs file's buffer,
> > you know you are doing something wrong.
> 
> Ok, while writing this out, I realized that to keep things still
> working, and to enable you to have an unlimited list of triggers, why
> not just turn the file into a binary sysfs file?
> 
> Yes, that's not what binary sysfs files are for, they are supposed to be
> only used for data that is "pass through" from userspace to hardware,
> where the kernel does not touch the information at all.  But I'm willing
> to give you an exception here as long as you document the heck out of it
> in the code itself, saying that no one else should ever copy this way of
> doing things again.
> 
> Would that work?

That would work, I guess.

We'll also want to limit number of triggers in LEDs -- there should be
one trigger "cpu" with parameters, not 1024 triggers "cpu0"
.. "cpu1023". But that will take some time to sort out.

Best regards,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html