Re: [PATCH] seq_file version of /proc/interrupts

[viro@parcelfarce.linux.theplanet.co.uk]

On Thu, Nov 13, 2003 at 10:36:26AM -0700, Jonathan Corbet wrote:
> While I was messing with the seq_file document, I went ahead and hacked up
> an implementation of /proc/interrupts.  This will be a first pass; if
> nothing else, it breaks every architecture except i386.  Fixing the others
> should not be hard, though I can't test them.  I've also misplaced my
> 100-CPU system somewhere, so I can't verify that it solves the initial
> problem.  But it should.
> 
> This version should scale to something over 300 processors, after which it
> will not be possible to fit even a single line of /proc/interrupts output
> into one page.  At that point, if this output format is even remotely
> useful, some sort of iterator which tracks interrupt and CPU numbers will
> be needed.

What the hell?  You *do* realize that seq_read() will increase the buffer
size if it can't fit the single entry into the current buffer, don't you?

Guys, there is no 4Kb limit.  At all.  You get longer entries - fine, the
thing will work.  It will grow buffer large enough to hold the longest
entry, though.

You don't *have* to preallocate buffer - it makes sense to do if you know
that one page will be too tight anyway, but it's not required.

You obviously want to keep entries reasonably small - exactly because users
can open the file and start reading from it.  Which will allocate (besides
the things normally allocated for any opened file) a buffer for said entries.

As long as it stays within several pages, there's no problem - after all,
you can always open a pipe and write to it / open a pair of AF_UNIX sockets
and send yourself datagrams / etc.  It's not that situation was unusual.
If you get buffer much bigger than that, you are asking for a DoS, obviously.