Re: PATCH: seq_file interface to provide large data chunks

[Matt Mackall <mpm@selenic.com>]

On Thu, Jul 10, 2003 at 11:19:07AM +0300, Vladimir Kondratiev wrote:
> 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/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;

This patch looks rather tab damaged.

I think it's problematic in that it can hold the semaphore for an
unbounded amount of time.

I'd suggest dropping and acquiring the semaphore each time through the
loop, but then you get into a situation where a second process can
cause the returned results to no longer be coherent. Since we'd no
longer have a way to get single results, this'd be bad.

-- 
Matt Mackall : http://www.selenic.com : of or relating to the moon