lkml.org 
[lkml]   [2007]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: NCPFS and brittle connections
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-02-05 04:53    [W:0.429 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site