linux-kernel - Re: Problem with freezable workqueues

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200703062357.13606.rjw@sisk.pl>
Date:	Tue, 6 Mar 2007 23:57:12 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	nigel@...el.suspend2.net
Cc:	Johannes Berg <johannes@...solutions.net>,
	Pavel Machek <pavel@....cz>, Gautham R Shenoy <ego@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...sign.ru>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>
Subject: Re: Problem with freezable workqueues

Hi,

On Tuesday, 6 March 2007 23:25, Nigel Cunningham wrote:
> On Tue, 2007-03-06 at 21:31 +0100, Rafael J. Wysocki wrote:
> > On Tuesday, 6 March 2007 01:30, Johannes Berg wrote:
> > > On Tue, 2007-02-27 at 22:51 +0100, Rafael J. Wysocki wrote:
> > > 
> > > > For 2.6.21-rc1 I've invented the appended workaround (works for me, waiting for
> > > > Johannes to confirm it works for him too), but I think we need something better
> > > > for -mm and future kernels.
> > > 
> > > Finally I could get back to this but after reading the thread I figured
> > > it might not be necessary to test this. Please let me know ASAP if you
> > > want this patch tested as well or it'll take quite a long time (going
> > > skiing for a week on Saturday)
> > 
> > I think it won't be necessary.
> > 
> > For now, we have decided to make the workqueues nonfreezable (the patch for
> > that has already been merged, AFAICT).
> > 
> > > In any case, I made the two xfs workqueues non-freezable and everything
> > > on my quad powermac works again, I also couldn't detect any filesystem
> > > correction.
> > 
> > Good, thanks for the confirmation.
> > 
> > > I wanted to adapt the BUG_ON(block IO not from suspend code) 
> > > patch from suspend2 but haven't gotten around to it yet.
> > 
> > That might be a good idea for other reasons too, but I'd prefer WARN_ON()
> > instead of BUG_ON() when you're at it. ;-)
> 
> I made it BUG_ON() because if Suspend2 is running any I/O coming from
> another source besides Suspend2 may be I/O on a page that's been used
> for the atomic copy, and in that case it would definitely be bad to
> write it to disk. If swsusp is running, the BUG_ON() won't trigger IIRC.

Okay, but I thought the idea was to use something similar that would trigger
for swsusp too (we would have to skip the IO from the userland suspend somehow,
BTW), and that I'd prefer to be WARN_ON() rather than BUG_ON().

Greetings,
Rafael
-
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/