linux-kernel - Re: Powertop shows events/0 waking at high rate due to ptys

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]

Date:	Mon, 27 Sep 2010 19:15:36 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Ian Jackson <Ian.Jackson@...citrix.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Subject: Re: Powertop shows events/0 waking at high rate due to ptys

On Mon, 27 Sep 2010 10:37:36 -0700
Jeremy Fitzhardinge <jeremy@...p.org> wrote:

>  Hi,
> 
> I noticed on one of my systems that powertop was showing events/0 waking
> at a high rate (~2000 times/sec, HZ=1000).  After a lot of tracing I
> found it was due to writes pending to ptys which hadn't been read.

Yes ptys will trigger this case while its there with a normal tty but
very hard to hit.

> problem; he reports that this wakeup behaviour is a regression compared
> to a 2.6.16 Debian kernel.

Be aware that you'll get misleading results to an extent with old
kernels. The old pty code is differently buggy and doesn't use the code
path in question at all.

With a non pty and care you can duplicate the problem on old kernels.

Really the line discipline should wake the work queue when it sets
tty->receive_room non-zero, but while only n_tty currently uses that
facility the existing code doesn't do it in any kind of race-free manner
and sometimes is only saved by the polling picking it up.

It's all really just a symptom of the fact that input and output buffers
shouldn't be attached to the tty in the first place but to a struct
representing the physical port. Fix that and the race conditions in
serial output go away, as do the potential crashes and this wakeup stuff
as well as a ton of locking in the irq/tx/rx paths. In several cases it
also saves you an entire copy.

Unfortunately while I got the tty port structures into lots of places
needed the job never gone done.

Alan
--
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/