LKML Archive on
help / color / mirror / Atom feed
From: Petr Vandrovec <>
To: Pierre Ossman <>
Cc: LKML <>
Subject: Re: NCPFS and brittle connections
Date: Sun, 04 Feb 2007 19:50:52 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.

  reply	other threads:[~2007-02-05  3:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-04 15:04 Pierre Ossman
2007-01-04 17:26 ` Petr Vandrovec
2007-01-04 19:30   ` Pierre Ossman
2007-01-05  7:43     ` Petr Vandrovec
2007-01-24 15:27       ` Pierre Ossman
2007-01-24 17:49         ` Petr Vandrovec
2007-01-24 22:01           ` Pierre Ossman
2007-01-25  8:22             ` Petr Vandrovec
2007-01-25 10:20               ` Pierre Ossman
2007-02-01  8:39                 ` Pierre Ossman
2007-02-04  6:00                 ` Petr Vandrovec
2007-02-04 17:17                   ` Pierre Ossman
2007-02-05  3:50                     ` Petr Vandrovec [this message]
2007-02-19 10:37                       ` Pierre Ossman
2007-02-20  2:47                         ` Petr Vandrovec
2007-02-20  6:37                           ` Pierre Ossman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: NCPFS and brittle connections' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).