In article <20000414005339.B4142@lrc.di.epfl.ch> you wrote:
> [ Cc list trimmed ]
[ Cc list lost, one of the disadvantages of reading through a news gateway ]
> almost static data. /proc currently does a good job at pretending the
> problem doesn't exist, because it can provide at least intra-record
> consistency.
Not even that if the record is larger than 3K.
> - locking: a request can acquire a lock while working on the variables
This seems to be always necessary if you want to provide consistent
data.
> - caching: ditto, but data is cached instead, changing the type of
> possible DoS attack
This too, unless you require user space to always provide a big enough
buffer that can fit all the data in a single read request.
> - versioning: /proc/bla/bla/version yields a string that changes whenever
> one of the variables in (atomic access domain) /proc/bla/bla changes
Sounds impractical as a generic scheme - modifying the version strings
for fast changing variables will be costly.
> I don't particularly like any of the two time-bomb approaches. In order
> to avoid the most obvious DoS problems, locking would probably need a way
> to "chain" reads, such that the kernel never has to wait for user space
> to release a lock. Caching could do the same, or just limit the
> per-process amount of such cached data.
What do you mean by "chaining" here?
Regards,
Borislav
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:24 EST