lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 7 Sep 2006 15:45:34 -0700 From: "Miles Lane" <miles.lane@...il.com> To: "Stefan Richter" <stefanr@...6.in-berlin.de> Cc: "Greg KH" <gregkh@...e.de>, "Andrew Morton" <akpm@...l.org>, linux1394-devel@...ts.sourceforge.net, LKML <linux-kernel@...r.kernel.org>, "Herbert Xu" <herbert@...dor.apana.org.au>, "Ben Collins" <bcollins@...ntu.com> Subject: Re: 2.6.18-rc5-mm1 + all hotfixes -- INFO: possible recursive locking detected On 9/6/06, Stefan Richter <stefanr@...6.in-berlin.de> wrote: > I wrote: > > I wrote: > >> 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) { > > This may be wrong anyway. According to include/linux/device.h, > class->sem should be used to protect access to class->children. There > are more places in nodemgr of this sort. > > >> 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); > >> } > > > > Hi Greg, > > > > perhaps you could advise on this. It appears from grepping through the > > sources that drivers/ieee1394/nodemgr.c is the only one with mixed > > access to device.bus->subsys.rwsem and class->subsys.rwsem. > > > > Other usages of subsys.rwsem that I found are: > > 1a.) dev->bus->subsys.rwsem > > driver/ide/ide-proc.c and drivers/net/phy/phy_device.c take > > dev->bus->subsys.rwsem. drivers/pnp/card.c takes dev.bus->subsys.rwsem. > > > > 1b.) driver.bus->subsys.rwsem > > drivers/s390/net/qeth_proc.c takes driver.bus->subsys.rwsem. > > > > 2.) class->subsys.rwsem > > drivers/scsi/hosts.c takes class->subsys.rwsem. > > > > 3.) bustype.subsys.rwsem > > drivers/input/serio/serio.c takes serio_bus.subsys.rwsem. > > drivers/input/gameport/gameport.c takes gameport_bus.subsys.rwsem. > > drivers/base/power/shutdown.c takes devices_subsys.rwsem. > > drivers/usb/core/devices.c and devio.c take usb_bus_type.subsys.rwsem. > > > > Do class->subsys.rwsem, bus->subsys.rwsem, and bus_type.subsys.rwsem > > point to identical or different lock instances? > > > > Either way, could it hurt to convert nodemgr to uniformly use > > ieee1394_bus_type.subsys.rwsem all over the place? I don't have time to do the bisection testing. If there is a patch you'd like me to test against 2.6.18-rc5-mm1+all hotfixes, please let me know. I apologize for not being able to narrow this down further for you. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists