seq_file interface, as it exist in last official kernel, never provides
more then one page for each 'read' call. Old read_proc_t did loop to
fill more than one page.
Following patch against 2.4.21 fixes seq_file to provide more than one
page if user requests it.
Many programs do read(large_buffer) once, instead of looping while
read()>0. They work wrong with seq_file. Also, one may expect read() to
provide whole information atomically (OK, relatively to other process
context stuff).
This patch loops over while some space remains in user provided buffer.
I am not subscribed to lkml, thus please cc: me (Vladimir Kondratiev
<vladimir.kondratiev@intel.com>) explicitly.
--- linux-2.4.21/fs/seq_file.c 2003-06-13 17:51:37.000000000 +0300
+++ linux/fs/seq_file.c 2003-07-10 10:47:53.000000000 +0300
@@ -55,6 +55,7 @@
return -EPIPE;
down(&m->sem);
+Again:
/* grab buffer if we didn't have one */
if (!m->buf) {
m->buf = kmalloc(m->size = PAGE_SIZE, GFP_KERNEL);
@@ -123,11 +124,14 @@
goto Efault;
copied += n;
m->count -= n;
+ size -= n;
+ buf += n;
if (m->count)
m->from = n;
else
pos++;
m->index = pos;
+ goto Again;
Done:
if (!copied)
copied = err;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:00:34 EST