linux-kernel - Re: [2.6.24 BUG] 100% iowait on host while UML is running

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: <x49ir3fhg5n.fsf@segfault.boston.devel.redhat.com>
Date:	Mon, 03 Dec 2007 11:55:16 -0500
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	zach.brown@...cle.com, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, jdike@...toit.com,
	user-mode-linux-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [2.6.24 BUG] 100% iowait on host while UML is running

Miklos Szeredi <miklos@...redi.hu> writes:

> On 2.6.24, top started showing 100% iowait on one CPU when a UML
> instance was running (but completely idle).  I've traced it to this
> commit [1].  Reverting it cures the problem.

Hi,

The UML code sits in io_getevents waiting for an event to be submitted
and completed.  This is a case I completely overlooked when putting
together the referenced patch.

We could check ctx->reqs_active before scheduling to determine whether
or not we are waiting for I/O, but this would require taking the
context lock in order to be accurate.  Given that the test would be
only for the sake of book keeping, it might be okay to do it outside
of the lock.

Zach, what are your thoughts on this?

-Jeff

[1] commit 41d10da3717409de33d5441f2f6d8f072ab3fbb6
--
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/