Socket related stuff - patch available for testing
Matthew Dillon
dillon at apollo.backplane.com
Wed Nov 11 18:53:39 PST 2009
Here's a patch, it needs some serious testing:
fetch http://apollo.backplane.com/DFlyMisc/tcp01.patch
The patch:
* Moves the socket pointer into the netmsg base structure, even
though some things don't use it, I know
* Adds a lwkt_port pointer to the socket structure and initializes
it to cpu0_soport()
* Expects network protocols to set so->so_port in their attach
functions, plus I do that for tcp and udp.
* Performs message chasing when the protocol port changes due to
e.g. a connect() or an implied connect or (I think) also an
implied binding to INADDR_ANY.
If a number of messages for a socket have built up on a protocol
thread and some operation in the protocol changes the socket's
protocol thread (aka implied connect), then any other messages
queued to that protocol thread, or new messages which race the
change, will automatically be forwarded to the correct protocol
thread when they are encountered.
* Fixes implied connects for TCP. This is when you use sendmsg()
with an address to imply a connect along with data, so data can
be sent along with the SYN.
Implied connects were completely broken and would crash the kernel.
Example: finger user at target (instant crash). finger uses the
implied connect feature.
* Cleans up a bunch of stuff. I was almost able to remove
the proto->pr_mport field entirely but sendmsg() still needs
to use it in the case where the passed address is non-NULL (aka
sendto() style). All other code that used to call proto->pr_mport()
now simply snarf the port out of so->so_port.
The mport functions themselves now basically just return so_port.
I left the sendmsg code intact just in case we wanted to optimize
it later on for UDP.
I found a few other bugs in the code but haven't fixed them yet. UDP
is not MPSAFE due to the global inpcbinfo (udbinfo) structure it uses.
This patch does need testing. I don't know what I might have blown up.
It's fairly straight forward so I would also appreciate a code review.
-Matt
More information about the Kernel
mailing list