linux-kernel - Re: [PATCH] Use tty

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: <469D2F67.40305@microgate.com>
Date:	Tue, 17 Jul 2007 15:06:47 -0600
From:	Paul Fulghum <paulkf@...rogate.com>
To:	James Simmons <jsimmons@...radead.org>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux console project <linuxconsole-dev@...ts.sourceforge.net>
Subject: Re: [PATCH] Use tty_schedule in VT code.

James Simmons wrote:
> Because sometimes you do want the delay. In other parts of the tty 
> code we do delay. What should be done is 

Correct, so we must stick with the delayed work structure
which requires calling the delayed work function.

>         if (tty->low_latency)
>                 flush_to_ldisc(&tty->buf.work.work);
>         else
>                 schedule_delayed_work(&tty->buf.work, 1);
> 
> Is this acceptable to you?

That does not make sense to me.

If you are calling from interrupt context, you do not want
to call flush_to_ldisc() directly regardless of low_latency.
This used to be the way it was done and it ended up causing
deadlocks in just that situation.

And the initial schedule has no reason to add the extra delay.

-- 
Paul Fulghum
Microgate Systems, Ltd.
-
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/