Calling trans_stat_show() from sysfs will overflow the string buffer when using the tegra30-devfreq driver. There are many frequencies on the transition table. When printing the table to the char buf it exceeds the buffer size of PAGE_SIZE / 4k. It is reproducible every time by invoking the devfreq sysfs interface. $ cat /sys/class/devfreq/6000c800.actmon/trans_stat Kernel log shows the buffer overflowing PAGE_SIZE: [ 782.459038] dev_attr_show: trans_stat_show+0x0/0x268 returned bad count [ 782.459179] fill_read_buffer: dev_attr_show+0x0/0x48 returned bad count It appears there is no guard in trans_stat_show() against systems that with a large frequency table.
Christian, could you take a look please?
CC'ing Chanwoo as well.
Can you describe the amount of frequency? An easy fix would be truncating the output but I don't think it would be a correct fix... If there isn't a bug in how the char are count I feel like the only solution is moving this to debugfs where there isn't the PAGE_SIZE limit.
(In reply to Christian Marangi (Ansuel) from comment #3) > Can you describe the amount of frequency? There are 20 available frequencies on the Tegra 30 "Ouya" device. $ cat /sys/class/devfreq/6000c800.actmon/available_frequencies 12750000 25500000 27000000 51000000 54000000 102000000 108000000 204000000 266500000 333500000 375000000 400000000 416000000 450000000 500000000 533000000 625000000 667000000 750000000 800000000
Thanks for the report. I checked how the equivalent function for cpufreq works and as I tought it does fail the thing to write exceed PAGE_SIZE. I sent a patch upstream that fix the missing check. sysfs stuff is ABI so moving this to debugfs is a no go (due to we don't break userspace rule) so this is the only solution currently. If accepted, it will be queued for stable backport.
BTW this has been fixed upstream and got backported. This can be closed as fixed.
Thanks.