Pete Zaitcev wrote:
On Tue, 11 May 2004 16:36:08 +0200
Rüdiger Plüm <[EMAIL PROTECTED]> wrote:


May 10 22:37:02 euler kernel: usbserial.c: too much data (112)
[]
Oops: 0002 2.4.21-20040509-debug #7 Mon May 10 12:04:53 CEST 2004


OK. The value of 112 means that you're running the earlier version
of the post_helper patch which was shipping with Fedora FC1 somewhere

Where do I find a newer version of the post_helper patch?


around linux-2.4.22-1.2176. This is known to break just as you describe
and a fix exists in Marcelo's tree since 2.4.26.

Now, about this:


+++ drivers/usb/serial/usbserial.c      2004-05-10 22:02:32.000000000 +0200
@@ -705,6 +705,17 @@
                return -EINVAL;
        }

+       if (!serial) {
+               static int rate_serial = 0;
+               /*
+                 * Check if serial is NULL, because this could lead
+                 * to a kernel panic.
+                */
+               if (++rate_serial % 1000 < 5)
+                  err("usb_serial structure is NULL");
+               return -EINVAL;

Ok, after a more intense code study I now know that it must be -ENODEV instead of -EINVAL.


+       }
+
        job = kmalloc(sizeof(struct usb_serial_post_job), GFP_ATOMIC);
        if (job == NULL)
                return -ENOMEM;


Even in the new code, write relies on tty->driver_data. You can oops
it by disconnecting in the right moment, especially on SMP.

OK, I see it seems to be a bigger problem. After some fast reading of the code I saw that the NULL pointer checks appear frequently and I understand that sometimes checks done before can be worthless at the point of time the structure is used because a disconnect may has happenend meanwhile (especially on SMP) which invalidates these structure.


The root cause of this is that disconnect is trying to close ports forcefuly but from the standpoint of the tty layer, only the user program can close. The right solution is to keep all structions

Thanks for that explanation. It makes things somewhat clearer to me.


necessary after the disconnect, only mark ports as disconnected.

This is simply not done in 2.4 currently. I might get to it once
the 2.4.26 percolates down and we see how it works.

Yes, this seems to be a very good solution. I saw your interesting discussion with Greg about this. Thanks for setting me on CC.



                job->len = POST_BSIZE;
+                count = job->len; /* Set count to job->len to give the correct
+                                     return value of data really written */


Fixed in 2.4.26, just use that code.

I am getting curious. Where is this fixed exactly in 2.4.26? The first thing I did before I wrote my own patch was to search the kernel patches from 2.4.22 till 2.4.26 (since I run 2.4.21) for changes of usbserial.c. I only found changes of usbserial.c in 2.4.22 and 2.4.23 which were already incorporated in my kernel sources (to be more precise I am using the latest 2.4.21 kernel sources for SuSE Linux 8.1 which already seem to contain some fixes from later kernels). So as I stumbled over this problem and made some thoughts about it I would like to have a look at the solution in 2.4.26 :-).

Regards

Rüdiger




------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to