seq_file's (fs/seq_file.c) implementation for read() do not allow more than one
page to be returned for one system call. This differs from old read_proc_t one:
old implementation used to loop until there is more data to provide.
This mean, programs that used to work fine with old implementation, will not
work with seq_file. I mean programs that do read(large_buffer) once. Strictly
say, correct action would be for program to loop while read()>0, but:
- 1. unfortunately, programs like 'xlogmaster' and 'mc' falls into this category;
- 2. by filling large buffer, we reduce number of syscalls
- 3. data returned by one syscall produced (or may be produced) atomically w.r.t
process context stuff, i.e. it is not the same to do one read() and multiple.
Steps to reproduce:
on 2.4.20 seq_file read() implementation is exactly the same, and good example
for large file that use seq_file is /proc/ksyms
strace -e read dd bs=10240 if=/proc/ksyms >/dev/null
It reveals that read() never return more than 4k.
Created attachment 556 [details]
patch to allow seq_file to return more than one page
I do loop while there is data to produce, using the same temporal buffer in the
kernel. I tested it with 2.4.21 kernel. Patch made for 2.4.21, but it applies
to 2.6.0-test1 with offset of 1 line
push the Again label after the kmalloc
Could you possibly send this patch to email@example.com for code
review, there have been a few concerns raised regarding a possible DoS, Thanks.
Vladimir, Alexander Viro had concerns about the DoS. I don't believe i saw the
patch posted on the linux kernel mailling list so perhaps you opted not to
persue it. So i shall close this bug as WILL_NOT_FIX. If you have concerns about
the resolution please contact me. Thank you.