| 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
| ||
|
Message-Id: <200707052138.56920.oliver@neukum.org> Date: Thu, 5 Jul 2007 21:38:56 +0200 From: Oliver Neukum <oliver@...kum.org> To: Miklos Szeredi <miklos@...redi.hu> Cc: pavel@....cz, paulus@...ba.org, stern@...land.harvard.edu, johannes@...solutions.net, rjw@...k.pl, linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org, mjg59@...f.ucam.org, benh@...nel.crashing.org Subject: Re: [linux-pm] Re: [PATCH] Remove process freezer from suspend to RAM pathway Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi: > > > Actually fuse allows SIGKILL, because it's always fatal, and the > > > syscall may not be restarted. > > > > I think you want to stick try_to_freeze() at the same places where you > > do SIGKILL handling. That should solve the 'syslogd is unfreezeable' > > problem. > > I could, but it would not solve the general problem. Namely, that the > presence of fuse imposes a certain ordering in which userspace tasks > have to be frozen. And it is not possible to know this ordering. Actually, why do you need this? There is no absolute need that you finish the request. You must either finish the request or let yourself be frozen. A quick look through fuse reveals principally request_wait_answer() And maybe a few other places. Is there some hidden reason you cannot handle being frozen here? Regards Oliver - 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