lkml.org 
[lkml]   [2006]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.18-rc5-mm1 + all hotfixes -- INFO: possible recursive locking detected
    Andrew Morton wrote:
    > On Tue, 5 Sep 2006 10:37:51 -0700
    > "Miles Lane" <miles.lane@gmail.com> wrote:
    >
    >> ieee1394: Node changed: 0-01:1023 -> 0-00:1023
    >> ieee1394: Node changed: 0-02:1023 -> 0-01:1023
    >> ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0080880002103eae]
    >>
    >> =============================================
    >> [ INFO: possible recursive locking detected ]
    >> 2.6.18-rc5-mm1 #2
    >> ---------------------------------------------
    >> knodemgrd_0/2321 is trying to acquire lock:
    >> (&s->rwsem){----}, at: [<f8958897>] nodemgr_probe_ne+0x311/0x38d [ieee1394]
    >>
    >> but task is already holding lock:
    >> (&s->rwsem){----}, at: [<f8959078>] nodemgr_host_thread+0x717/0x883 [ieee1394]
    [...]

    This information confuses me. These places are not supposed to be the
    ones where the locks were actually acquired, are they?

    > That's a 1394 glitch, possibly introduced by git-ieee1394.patch.

    Or maybe it's older. Nodemgr takes class->subsys.rwsem and
    device.bus->subsys.rwsem. It always did. Could there be a change in
    driver core which makes this recursive? Or has it always been recursive?
    For example,

    static void nodemgr_update_pdrv(struct node_entry *ne)
    {
    struct unit_directory *ud;
    struct hpsb_protocol_driver *pdrv;
    struct class *class = &nodemgr_ud_class;
    struct class_device *cdev;

    down_read(&class->subsys.rwsem);
    list_for_each_entry(cdev, &class->children, node) {
    ud = container_of(cdev, struct unit_directory, class_dev);
    if (ud->ne != ne || !ud->device.driver)
    continue;

    pdrv = container_of(ud->device.driver, struct hpsb_protocol_driver,
    driver);

    if (pdrv->update && pdrv->update(ud)) {
    down_write(&ud->device.bus->subsys.rwsem);
    device_release_driver(&ud->device);
    up_write(&ud->device.bus->subsys.rwsem);
    }
    }
    up_read(&class->subsys.rwsem);
    }


    Miles,

    perhaps you should rather unapply all 1394 patches at once.
    git-ieee1394.patch is alas the lowermost patch of a stack of dependent
    patches. I somehow expect that the "possible recursive locking" persists
    even if all the 1394 patches were removed.

    Thanks in advance,
    --
    Stefan Richter
    -=====-=-==- =--= --=-=
    http://arcgraph.de/sr/
    -
    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: 2006-09-05 21:27    [W:0.026 / U:0.340 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site