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: Mon, 23 Jul 2007 10:04:43 +1000 From: Paul Mackerras <paulus@...ba.org> To: Nigel Cunningham <nigel@...el.suspend2.net> Cc: Alan Stern <stern@...land.harvard.edu>, david@...g.hm, Miklos Szeredi <miklos@...redi.hu>, nigel@...pend2.net, linux-kernel@...r.kernel.org, miltonm@....com, ying.huang@...el.com, linux-pm@...ts.linux-foundation.org, Jeremy Maitin-Shepard <jbms@....edu> Subject: Re: [linux-pm] Re: Hibernation considerations Nigel Cunningham writes: > I guess I want to persist because all of these issues aren't utterly > unsolvable. It's just that we don't have the infrastructure yet to > figure out the solutions to these issues trivially. Take, for example, Ever heard of the halting problem? :) It's not just a matter of infrastructure. You very quickly get into questions that are mathematically undecideable. > the locking issue. If we could call some function to say "What process > holds this lock?", then task A could know that it's waiting on task B > and put that information somewhere. We could then use the information > to freeze task B before task A. But how would that help? If task B holds the lock, then we can't freeze it until it's released the lock. Then the question is, what does task B need in order to get to the point where it releases the lock? And so on. It rapidly gets not just extremely messy, but actually impossible to compute in general. Paul. - 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