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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 29 Mar 2019 11:26:06 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Marek Behun <marek.behun@....cz>
Cc:     Pavel Machek <pavel@....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?

On Fri, Mar 29, 2019 at 11:24:36AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 29, 2019 at 09:48:23AM +0100, Marek Behun wrote:
> > > pavel@amd:~/cip$ cat /sys/power/state
> > > freeze mem disk
> > > pavel@amd:~/cip$ cat /sys/class/leds/phy0-led/trigger
> > > none bluetooth-power rfkill-any rfkill-none kbd-scrolllock kbd-numlock
> > > kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock
> > > kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock
> > > AC-online BAT0-charging-or-full BAT0-charging BAT0-full
> > > BAT0-charging-blink-full-solid rfkill0 phy0rx phy0tx phy0assoc
> > > phy0radio [phy0tpt] mmc0 timer heartbeat audio-mute audio-micmute
> > > rfkill1 hci0-power rfkill8
> > > pavel@amd:~/cip$
> > > 
> > 
> > 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?

greg k-h