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: Sun, 24 May 2009 10:30:25 -0400 (EDT) From: Alan Stern <stern@...land.harvard.edu> To: "Rafael J. Wysocki" <rjw@...k.pl> cc: Johannes Berg <johannes@...solutions.net>, Oleg Nesterov <oleg@...hat.com>, Ingo Molnar <mingo@...e.hu>, Zdenek Kabelac <zdenek.kabelac@...il.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, pm list <linux-pm@...ts.linux-foundation.org> Subject: Re: INFO: possible circular locking dependency at cleanup_workqueue_thread On Sun, 24 May 2009, Rafael J. Wysocki wrote: > The patch is appended for reference (Alan, please have a look; I can't recall > why exactly we have called device_pm_lock() from the core suspend/hibernation > code instead of acquiring the lock locally in drivers/base/power/main.c) and > I'll attach it to the bug entry too. I can't remember the reason either. Probably there wasn't any. The patch looks fine, and it has the nice added benefit that now the only user of device_pm_lock() will be device_move(). > --- > From: Rafael J. Wysocki <rjw@...k.pl> > Subject: PM: Do not hold dpm_list_mtx while disabling/enabling nonboot CPUs > > We shouldn't hold dpm_list_mtx while executing > [disable|enable]_nonboot_cpus(), because theoretically this may lead > to a deadlock as shown by the following example (provided by Johannes > Berg): > > CPU 3 CPU 2 CPU 1 > suspend/hibernate > something: > rtnl_lock() device_pm_lock() > -> mutex_lock(&dpm_list_mtx) > > mutex_lock(&dpm_list_mtx) > > linkwatch_work > -> rtnl_lock() > disable_nonboot_cpus() > -> flush CPU 3 workqueue > > Fortunately, device drivers are supposed to stop any activities that > might lead to the registration of new device objects and/or to the > removal of the existing ones way before disable_nonboot_cpus() is Strictly speaking, drivers are still allowed to unregister existing devices. They are forbidden only to register new ones. This shouldn't hurt anything, though. > called, so it shouldn't be necessary to hold dpm_list_mtx over the > entire late part of device suspend and early part of device resume. > > Thus, during the late suspend and the early resume of devices acquire > dpm_list_mtx only when dpm_list is going to be traversed and release > it right after that. Acked-by: Alan Stern <stern@...land.harvard.edu> -- 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