I'm not sure whether that you see is really a bad NFS packet. It's
much more likely a side effect of the server side XDR routines. I'm
assuming you've been running your network sniffer on the NFS server? Try
again running it on a different box.
When XDR is asked to decode a string, it avoid allocating memory
for it (this has been a major bottleneck). What it does instead
is just use the string as given in the RPC packet, and tack on
a NUL byte. What if there's no room in the packet because
the string is an exact multiple of 4 bytes, which is the alignment
XDR uses? It just moves the string by four bytes, and tacks on the
NUL byte then.
Here's how the RPC packet looks
0000 0008 636f 6e66 6967 2e68
^^^^^^^^^^^^^^^^^^^- config.h, without NUL byte
^^^^^^^^^--------------------- string length, i.e. 8
When the XDR routine decodes the packet, it finds the string length is
a multiple of 4, and moves the string
636f 6e66 6967 2e68 0067 2e68
^^^^^^^^^^^^^^^^^^^----------- config.h, moved 4 bytes
^^-------- NUL byte added
^^^^^^^- junk
The obvious gain is of course that this avoids all memory allocations,
and even 3 out of 4 string copies.
The drawback of the approach is that it confuses the Linux raw packet
handling, which expects that skb's once received never get modified.
I know it's evil, but so far you're the first one to notice :-)
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir@caldera.de +-------------------- Why Not?! -----------------------
UNIX, n.: Spanish manufacturer of fire extinguishers.
-
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/