Distribution: Hardware Environment: Software Environment: Problem Description: 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 do 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 linux-kernel@vger.kernel.org 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.