I wrote:
> The last item is expensive and allows obvious DoS attacks. You already
> get fairly good consistency even without it, e.g. the "no parent" case
> is already solved by not showing additions after open.
That's wrong, sorry. You can still get an orphan if the parent dies while
you're reading procsnap. A simple "almost correct" fix would be to assume
that its parent is now init.
This creates an inconsistency if a parent ensures that all its children
are dead before it terminates itself. You can avoid this by re-reading
procsnap and removing all orphaned children that you don't see anymore
in the second round.
There is still a create-death race if a process is guaranteed to exist
before another one dies, but this is probably a quite exotic scenario.
(There may be more potential inconsistencies of this type.) Correctly
solving this requires to defer process death.
BTW, another issue is structure independence: exposing the plain task
structure to user space is undesirable (version conflicts). You can
either define your own "stable" structure and copy/convert the
corresponding fields, or you can provide a structure description for
the fields user space may be interested in, e.g.
<name> <offset_in_bytes> <length_in_bytes>
The latter is cheaper for the kernel but requires a /proc file for the
description, unless you want to mix description and a actual data in
the same file.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- 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:11 EST