lkml.org 
[lkml]   [2007]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [1/2] 2.6.22-rc7: known regressions
    (CC list trimmed)

    On Thu, 5 Jul 2007, Dmitry Torokhov wrote:

    > > > NIP [c001870c] strlen+0x4/0x18
    > > > LR [c0134fec] kobject_get_path+0x34/0xc4
    > > > Call Trace:
    > > > [eed5be90] [c01d5124] class_uevent+0xac/0x1bc
    > > > [eed5bed0] [c01357e4] kobject_uevent_env+0x23c/0x460
    > > > [eed5bf20] [c01d485c] class_device_del+0x178/0x1a0
    > > > [eed5bf40] [c01d489c] class_device_unregister+0x18/0x30
    > > > [eed5bf60] [c021f820] input_unregister_device+0xf4/0x130
    > > > [eed5bf70] [c0242f4c] hidinput_disconnect+0x2c/0x60
    > > > [eed5bf90] [f27f2bac] hidp_session+0x550/0x584 [hidp]
    > > > [eed5bff0] [c0013e28] kernel_thread+0x44/0x60
    [...]
    > > I'm not seeing any reference counting or other protection for the device
    > > ("input") on "hid->inputs" list. But I don't know the code. Dmitry? Jiri?

    This should be automatically done by proper dev.parent setting of the
    corresponding input device, as already mentioned by Dmitry.

    > This should pin hid object untill all inputs are released. However
    > bluetooth does not use driver model and does not have hid->dev set up
    > and so it looks like we are simply trying to unregister an input device
    > that is already gone... I still don't quite get how we unregister the
    > same device twice - it is done from a per-hid-device thread in hidp...

    Actually even bluetooth HID seems to set up hid->dev correctly in
    hidp_setup_hid() and also sets properly dev.parent in hidp_setup_input().

    Marcel, what is please the point behind this code in
    hidp_add_connection():

    if (!session->hid) {
    session->input = input_allocate_device();
    if (!session->input) {
    kfree(session);
    return -ENOMEM;
    }
    }

    I suspect that the oops happens during freeing this extra device which is
    not allocated inside hid core, but I can't immediately see from the code
    what is the exact purpose of this 'extra' input device and why don't the
    input devices allocated and registered in hidinput_connect() suffice?
    usbhid doesn't need to register any extra input devices, everything is
    handled solely in hid-input core.

    Seems like it could be triggered by ioctl() with ca->req->rd_size set to
    0, but I am not that familiar with the bluetooth code to see it
    immediately.

    Thanks,

    --
    Jiri Kosina
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-07-07 00:49    [W:2.190 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site