linux-kernel - Re: [PATCH] detour TTY driver

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 for Android: free password hash cracker in your pocket

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

Message-Id: <1277767665.2348.51.camel@itpsd6lap>
Date:	Tue, 29 Jun 2010 01:27:45 +0200
From:	Samo Pogacnik <samo_pogacnik@....net>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-embedded <linux-embedded@...r.kernel.org>,
	linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] detour TTY driver - now ttyprintk

Dne 27.06.2010 (ned) ob 14:35 +0100 je Alan Cox zapisal(a):
> > I thought that this would automatically reduce processor load, which is
> > obviously not the case. Sorry for the delay, but i am trying to figure
> > out how to slow down write method when under pressure.
> 
> Ok I played with this a bit. Much to my surprise until I thought about it
> in detail it all works fine without any of the ratelimiting at all. There
> is a problem if you manage to redirect the console *in kernel* to the
> printk driver, but that needs stopping anyway and rate limit won't fix it
> (you blow the stack before it kicks in)
> 
> In the case where userspace loads it hard and its a graphical console
> then we use a lot of CPU power drawing stuff on screen, but killing the
> process does as is expected.
> 
> With a serial console the printk itself blocks which blocks the line
> discipline which in turn slows stuff down.
> 
> The only two bad things I can see how to cause are
> 
> - Slowing down output by stuffing lots of extra data into the port (which
>   I can do anyway just fine) so isn't worse than before.
> 
> - Filling up the dmesg log easily and hiding important messages. Not
>   really a problem in this case bcause the whole point of this is
>   embedded and capturing those messages as if they were system ones.
> 
> So much to my surprise the flow control is a red herring and best left
> out.
> 
> Alan

If without flow control, do you think it makes sense to very slowly
introduce more and more delay (interruptible) into tty's write operation
when output rate is "too" high? That way non-error conditions would not
suffer (not discarding any messages, only delaying additional 1 msec on
100 writes), when ratelimit would have been exceeded from time to time.
And on the other hand endless high-volume output, which is probably an
error condition, would slowly give away more and more of its processing
time. Maybe this would also help if output is made on behalf of some
high RT-prioritized process?

Of course, i can easily remove ratelimiting as well, if the situation
with flow control isn't clear and this only complicates things.

Samo


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