On 12/11/2013 07:45 AM, Greg KH wrote: > I need an ack from Thomas or some other debugobjects-knowledgable > developer before I can take this...
I have a v3 which I haven't posted yet. Basically the whole thing seems to work. "Seems" means that I get a bunch of backtraces which I haven't checked to see if it is a kref-accounting bug (something that should be fixed) or something that is correct but kref isn't used properly. One example is serial port init via tty_port_init(): It initializes &port->kref. To use that kref you need to use tty_port_get()/put() and more importantly dynamically allocate tty_port _or_ provide port->ops->destruct callback. This seems not be done by everyone, for instance gs_port_alloc() [0]. The question is this a bug and should be fixed (and kref's debugobject is right here) or it is "legal" behavior. I get another backtrace on "rmmod sg" which shows ODEBUG: free active (active state 0) object type: kref hint: kset_init+0xe/0x30 [<c112fec8>] kfree+0x128/0x280 [<c13784c2>] ? class_release+0x22/0x30 [<c13784c2>] class_release+0x22/0x30 [<c12da3bd>] kobject_cleanup+0x2d/0x70 [<c12da2c7>] kobject_put+0x67/0xa0 [<c12da34f>] kset_unregister+0xf/0x20 [<c13787b3>] class_destroy+0x23/0x30 [<f850ee62>] exit_sg+0x17/0x3c [sg] so it is triggered by class_destory() and I haven't have the time check what is wrong here. Based on this I would like to know what could be the best way forward here. Post v3 and work on this backtraces before it gets merged or after it gets merged. [0] drivers/usb/gadget/u_serial.c > thanks, > > greg k-h > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
