Bug 11856
Summary: | seq_file does not handle pread() | ||
---|---|---|---|
Product: | File System | Reporter: | Petr Vandrovec (vandrove) |
Component: | Other | Assignee: | Alexey Dobriyan (adobriyan) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | adobriyan, earl_chew, florian, rjw |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.28-rc1 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Petr Vandrovec
2008-10-25 17:40:54 UTC
BTW, does anything but 0 offset is used? crap, ->read hook has absolutely no way of telling read from pread No, in real app it is used with offset 0 only. I've looked at code, and it looks to me like that modifying seq_file itself to handle pread is not that hard if you are OK with saying that if you mix read() and pread() you are on your own. That's why I did not assign it to you... Well, /proc/uptime issue is fixed by moving /proc/uptime away from seq_file, so it is not regression anymore, but it does not fix what subject of this bug says - that seq_file does not handle pread, so issue may resurface at any time when some other file gets converted to seq_file... commit 8f19d472935c83d823fa4cf02bcc0a7b9952db30 "seq_file: properly cope with pread" and previous patches. (In reply to comment #4) > Well, /proc/uptime issue is fixed by moving /proc/uptime away from seq_file, > so > it is not regression anymore, but it does not fix what subject of this bug > says > - that seq_file does not handle pread, so issue may resurface at any time > when > some other file gets converted to seq_file... https://lkml.org/lkml/2012/1/18/21 A patch referencing this bug report has been merged in Linux v3.4-rc1: commit 7904ac84244b59f536c2a5d1066a10f46df07b08 Author: Earl Chew <echew@ixiacom.com> Date: Wed Mar 21 16:33:43 2012 -0700 seq_file: fix mishandling of consecutive pread() invocations. |