> Could you inform me what you are talking about?
Actually, I said: pushing back open requests on socket, got via
hash table lookup.
Normally openrequests were born only under bh lock, and accepted
under process lock. khttpd pushes back openrequests under user lock.
Another, but related, thing: khttpd grabs user lock on socket
stolen from hash table. It breaks one of basic assumptions:
backlogging does not occur, if socket is orphan.
> If there is an issue with
> kHTTPd having a negative effect on other parts of the kernel, I would like
> to know. (If I don't know about such things, I cannot solve them)
The first problem was mainly unsolvable inside khttpd.
It is impossible to get bh lock in user process context. It is already
solved (to 2.3.15) inside TCP, and solution is not so bad.
Actually, later it even allowed to relax some constraints for
backlog processing, so that the result is not purely negative 8).
The second flaw is more or less easy: if khttpd kept slave socket open,
as all normal users do, rather than stole it from hash table,
it would remove the problem.
Alexey
-
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/