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:32:52 +0100
From:   Pavel Machek <>
To:     Greg Kroah-Hartman <>
Cc:     Marek Behun <>, Tejun Heo <>,,
        Jacek Anaszewski <>
Subject: Re: kernfs: can read/write method grow buffer size?

> 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.

Are we doing something wrong?

I don't think so. It looks like sysfs has arbitrary limit it should
not have.

Can we get that fixed? Because userland already knows about this
interface, it is one-type-of-value-per-file, and just removing the
limit seems to be the best way forward.

(cesky, pictures)

Powered by blists - more mailing lists