Re: getting more that 4K out of a proc file? [PATCH]

[Rusty Russell]

In message <[e-mail]> you write:
> "A month of sundays ago Rusty Russell wrote:"
> > 	I put the startpos hack in originally (as shown in comment):
> > for reading firewall rules (which can be variable length), I wanted to
> > store the rule *number* in the file offset, not the number of bytes
> > offset, but didn't want to hack the internal proc interface.  I didn't
> > try to use it to read > 3k.
> 
> OK. I don't know from reading the code whether it will or will not mix
> well with the >3K functionality (or even if the latter was planned).
> All I  can say is that the >3K is apparently working. now that
> we have figured out how it was meant to be triggered. 

You can figure it yourself, fairly easily.  If you happen to make
start point at something less than the page pointer, it will assume
that you wanted that value to be interpreted as a file offset to be
added.  So providing >3k by ignoring the page provided and pointing
`start' to a large static area all of your own will ONLY work if that
area happens to have an addr > page.  That's a disaster waiting to
happen.

Yes, the start hack can now be removed: it was insufficient, and
AFAIK, it was only used in the (removed-in-2.3) ip_fw.c code.

> Storing the rule number in ppos seems strange. I think you should
> have kept the natural ppos semantics and used a map ppos<->rule index.

Which I keep uptodate as rules get inserted and deleted, how exactly?
I don't think you understand the problem.  The solution could have
been to insist that all rules be formatted to uniform length (like the
2.0 ip_fw.c code tried to do, only they used %9u not %10u for the
counters and so failed).

> > the kernel is flawed.  What language do humans speak?  There isn't
> > much motiviation to try to fix something that isn't really fixable.
> 
> Well, I disagree, but that's beside the point.

This one I'll address off-line.

Rusty.
--
Hacking time.