Bug 952 - seq_file badly handle files larger than 1 page
Summary: seq_file badly handle files larger than 1 page
Alias: None
Product: File System
Classification: Unclassified
Component: Other (show other bugs)
Hardware: i386 Linux
: P2 high
Assignee: Zwane Mwaikambo
Depends on:
Reported: 2003-07-17 14:14 UTC by Vladimir Kondratiev
Modified: 2003-10-30 16:10 UTC (History)
0 users

See Also:
Kernel Version: 2.6.0-test1
Tree: Mainline
Regression: ---

patch to allow seq_file to return more than one page (518 bytes, patch)
2003-07-17 14:18 UTC, Vladimir Kondratiev
Details | Diff

Description Vladimir Kondratiev 2003-07-17 14:14:09 UTC
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


strace -e read dd bs=10240 if=/proc/ksyms >/dev/null

It reveals that read() never return more than 4k.
Comment 1 Vladimir Kondratiev 2003-07-17 14:18:05 UTC
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
Comment 2 Zwane Mwaikambo 2003-07-29 19:16:26 UTC
push the Again label after the kmalloc
Comment 3 Zwane Mwaikambo 2003-09-02 22:56:49 UTC
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.
Comment 4 Zwane Mwaikambo 2003-10-30 16:10:29 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.