Re: NCPFS and brittle connections

[Petr Vandrovec]

Pierre Ossman wrote:
> Petr Vandrovec wrote:
> > Problem is with these pointers - reply_buf & server->packet.  Now code
> > will just read packet from server->packet, and write result to
> > reply_buf, most probably transmiting some random data to network, and
> > overwriting innocent memory on receiption...  I believe that you need
> > to make copies of server->packet/size for transmission, and some
> > simillar solution for receive as well.  As both request & response can
> > be up to ~66000 bytes.
>
> Hmm.. I thought server->packet was protected until the packet was
> completed, independent of the process that issued it. Looking closer I
> see that this isn't quite the case.
>
> How about this... We allocate two buffers at startup, one for outgoing
> and one for incoming. Then we use these during the actual transmission,
> copying back and forth as need. Then we just need to avoid the final
> response copy if the process has gone belly up.

You must not allow anybody to reuse transmit buffer until you are done 
with all retransmits and received reply from server...  That's why code 
uses same buffer for both request and reply - you never need both, and 
as maximum size is more or less same for both (65KB), it avoid problem 
that you would need two 65KB buffers in worst case.

> Now my next question in that case is, what is the purpose of
> server->packet. Couldn't this buffer be provided by the caller like the
> response buffer?

Then you would need to do vmalloc (or maybe kmalloc for some cases) on 
each request transmit & receive.  And only very few callers provide 
receive buffer - most of them does ncp_request() which receives reply to 
server->packet, without doing any additional allocation - there are only 
three callers which use ncp_request2 - two of them (ioctl, 
ncp_read_bounce) do that because copy_to_user is not allowed while 
ncp_server is locked, and third one (search for file set) does that 
because caller may need to issue additional NCP calls while parsing its 
result.  But everybody else gets away with no memory allocation.
								Petr


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/