All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Dumitru <doug@easyco.com>
To: user-mode-linux-devel@lists.sourceforge.net
Subject: [uml-devel] Patch for arch/um/drivers/line.c to fix buffer error
Date: Sun, 27 Jun 2004 23:06:05 -0700	[thread overview]
Message-ID: <40DFB54D.5040109@easyco.com> (raw)

All,

I have been fighting a buffering error when sending large amounts of 
data out pty devices from UML.  I have tried a couple of patches that 
did not really fix the problem (and were rightly rejected by the group), 
but have finally found the real bug.

In /arch/um/drivers/line.c there is a function "buffer_data" that is 
responsible for storing data into the lines ring buffer.  The function 
is "supposed" to return the number of characters actually buffered. 
Unfortunately, in the case where the buffer wraps, the "len" variable is 
decremented by "end" before it is used as the return parameter.

Here is a patch that fixes this.

--- linux-2.4.26-um/arch/um/drivers/line.c      2004-06-28 
01:46:21.000000000 -0400
+++ linux-2.4.23-um/arch/um/drivers/line.c      2004-06-28 
01:45:35.000000000 -0400
@@ -72,9 +72,9 @@
         else {
                 memcpy(line->tail, buf, end);
                 buf += end;
-               len -= end;
-               memcpy(line->buffer, buf, len);
-               line->tail = line->buffer + len;
+               //len -= end;
+               memcpy(line->buffer, buf, len - end );
+               line->tail = line->buffer + len - end;
         }

         return(len);

There is actually another bug in this area, but I am still working on a 
"good" fix for this.  The scenario is this:

   o An application opens an output device (ie /dev/serial/13)
   o It pushes stuff do the device
   o It closes the device

This would be like:

   cat /etc/termcap > /dev/serial/13

The problem is that the device will close while there is still data 
buffered in the ring buffer (and the ring-buffered data will not be 
transfered to the device).  This is a pretty complicated scenario to 
handle completely, so I have not tried to put together a patch for this 
(plus it does not directly impact my customers at this point).  In 
theory, handling all of these situations might require changes to how 
the ring-buffering is implemented (or maybe can the ring-buffer be 
eliminated all together).  Suggestions on how to implement this would be 
appreciated.

--------------------------------------------------------------------
Doug Dumitru     800-470-2756     (610-237-2000)
EasyCo LLC       doug@easyco.com  http://easyco.com
--------------------------------------------------------------------



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

             reply	other threads:[~2004-06-28  6:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-28  6:06 Doug Dumitru [this message]
2004-08-17 19:50 ` [uml-devel] Patch for arch/um/drivers/line.c to fix buffer error BlaisorBlade

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=40DFB54D.5040109@easyco.com \
    --to=doug@easyco.com \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.