lkml.org 
[lkml]   [2001]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [CFT][PATCH] large /proc/mounts and friends


On Mon, 15 Oct 2001, Linus Torvalds wrote:

>
> On Mon, 15 Oct 2001, Linus Torvalds wrote:
> >
> > (In other words: with a structured approach you can make guarantees about
> > the stability of each entry - you just can't necessarily guarantee that
> > all entries are shown or that some entries might not be duplicated..)
>
> Note that this can actually be important, with suid applications that
> trust /proc. It is a GoodThing(tm) to have a read() that never returns
> "mixed" output from different lines, ie even if a mount/umount happens in
> parallel with reading /proc/mounts, you never get the filenames wrong..

Already done, and yes, reasons were precisely what you've mentioned.

> Some stuff definitely wants more than 1 page per entry (/proc/mount
> happens to be the only one I can think of - it can have the pathname
> already be PAGE_SIZE-1, with the options being another PAGE_SIZE), so some
> interface like

Also handled - we expand the buffer if needed.

> - "proc_read_data" data structure:
>
> struct proc_read_data {
> struct semaphore sem;
> int (*fillme)(struct proc_read_data *);
> unsigned long this_index;
> unsigned long next_index;
> unsigned int buffer_len;
> char buffer[0];
> };

Bingo. Except that I do separate allocation of buffer.

> - allocate it on /proc open, de-allocate it on close, save it away in
> filp->f_private_data or whatever...

Exactly, except that there's no reason to limit it to procfs.

> .. and that's it (except for "fillme()", which is obviously the hard part,
> and which has to fill in not only the buffer with the data for the right
> index, it also has to fill in "prd->next_index" and "prd->buffer_len".
>
> Al, do you see any problems in this? I bet a lot of /proc files will fit
> this model, and need only a fairly simple "fillme()" function..

It's _very_ close to what I've done.

> Also note that because we cache _one_ entry, we absolutely _guarantee_
> that a user that just does consecutive "read()" calls will never _ever_
> see inconsistent lines, regardless of what his size of the read buffer is.

Right. We should never leave more than one entry in buffer - we have every
right to try and fill several, as long as we know that all but the last one
will be immediately eaten.

Check the previous mail I've sent - it contains pretty straightforward
pseudocode for seq_read(). Aside of the fact that seq_read() simply
doesn't bother with sub-record resolution, it's pretty close to your
function.

BTW, I've missed check for pread() - good thing that you've mentioned
it in your variant...

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:08    [W:0.069 / U:4.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site