On Wed, Feb 24, 2016 at 11:22:49PM +0000, tilman wrote:
>
> > I suggest staying away from eclipse, that's not needed for kernel
> > development. Other than that, it's just normal debugging, good luck
> > with that :)
> I resorted to good old vi as the editor that starts up fastest :-)
>
> And I traced down the problem -- but not the root cause:
>
> In usbrsa_attach, I allocate a private struct for port specific/driver
> specific data:
>
> static int usbrsa_attach(struct usb_serial *serial)
> {
> int i = 0;
> int ret = 0;
> struct usb_serial_port* serport;
> struct usbrsa_port_private* priv = NULL;
> ...
> for (i = 0; i < serial->num_ports; i++)
> {
> serport = serial->port[i];
>
> // allocate struct for driver's private data
> priv = kmalloc(sizeof(struct usbrsa_port_private), GFP_KERNEL);
> ....
> usb_set_serial_port_data(serport,priv);
> ...
> }
>
>
> In usbrsa_release, the pointer to the private struct has become a NULL
> pointer -- even though the pointer was not manipulated in between by
> usbrsa_open or usbrsa_write. In fact, I have dumped the pointer in all other
> functions like usbrsa_open, usbrsa_writeroom etc., and it is correct. The
> null pointer in usbrsa_release then leads to a pointer dereferencing error
> in release_baudrate_lcr_urb(priv);
>
> static void usbrsa_release(struct usb_serial *serial)
> {
> int i;
> struct usbrsa_port_private* priv;
> struct usb_serial_port* serport;
> ...
>
> for (i = 0; i < serial->num_ports; i++)
> {
> printk("%s: Mark1\n",__func__);
> serport = serial->port[i];
> priv = usb_get_serial_port_data(serport);
> printk("%s: Mark2\n",__func__);
> printk("%s: private struct at %p\n",__func__,priv);
> printk("%s: Mark2a ",__func__);
> release_baudrate_lcr_urb(priv);
>
> Here the kernel log
> [ 1856.366874] usbrsa_release: Mark2
> [ 1856.366876] usbrsa_release: private struct at (null)
> [ 1856.366878] usbrsa_release: Mark2a release_baudrate_lcr_urb: Start
> [ 1856.366904] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000102
>
> This could mean that usb_get_serial_port_data does not always work correctly
> -- which I find rather unlikely. Are there any limitations known, for
> instance when using the usb_get_serial_port_data in an SMP environment? Any
> suggestions in which direction to dig?
Release your port data in the port_remove callback, not the release
callback. The release callback is for when your whole device is
removed, not the individual ports.
Try that and see what happens...
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
